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ABSTRACT 


A virtual world provides an exceptional resource for the testing and development of an 
Autonomous Underwater Vehicle (AUV). The difficulties associated with the underwater 
environment are numerous and complex. In order to properly verify vehicle results in the laboratory 
such a world must accurately model the physics associated with the vehicle, its submerged 
hydrodynamics characteristics, and interactions with the environment. Environmental effects such as 
wave motion, currents, and flow forces created by bodies moving through the water can cause 
unpredicted performance variations and failures in the ocean environment. The current Phoenix AUV 
virtual world includes steady-state ocean currents, but does not take into account the environmental 
effects of waves and flow forces induced by adjacent vehicles (such as a moving submarine docking 
target). 

This work provides a thorough real-time simulation of these complex factors using physically 
based models. The problem is broken down into wave motion effects, submarine-induced flow fields, 
and virtual sensors to improve AUV motion control. Each set of forces are thoroughly analyzed and 
realistically simulated in real-time through the algorithms developed. In order to maintain real-time 
response, perturbations in the flow field caused by the AUV itself are assumed to be negligible. 
simulated testing is performed across a range of easy to worst-case scenarios in order to justify 
assumptions. Extensive testing using virtual sensors is used to develop adequate control algorithms in 
the presence of turbulent cross-body flow. 

The result of this research is an enhanced virtual world which more accurately depicts the 
ocean environment, along with the models and control algorithms required to design and operate an 
AUV during submarine launch and recovery. A platform independent approach to virtual environment 
simulation is presented through the use of the Virtual Reality Modeling Language (VRML) and Java. 
Finally, simulation test results provide strong evidence that AUV control with actual cross-body flow 
sensors can enable stable navigation, first through a turbulent flow field and then for subsequent 


docking with a moving submarine. 
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I. INTRODUCTION 


A. BACKGROUND 


The end of the cold war has shifted the international balance of military strength. Today's 
United States Navy is undergoing a major reorganization. Our naval mission has moved from an 
open-water strategy to littoral warfare. A paradigm shift of such proportions brings with it the need 
for new strategies, technologies, and insights. Meanwhile public pressure demands reduced military 
funding and resources. These factors are creating challenging situations as a smaller military attempts 
to meet broader range of missions with fewer resources. Highly capable, low-cost underwater robots 
provide promising new capabilities which might be used to enhance military readiness while relieving 
the stress associated with broader mission goals. 

While robots are not a valid solution for every problem domain, mine warfare is a mission 
area that is extremely pertinent. Mine warfare is a naval tactic that can be easily used by any potential 
enemy. It is a low-cost, low-risk measure which is very effective and hard to oppose. 

The Naval Postgraduate School (NPS) Autonomous Underwater Vehicle (AUV) Research 
Group is actively working to provide a solution to this defense problem. The Phoenix AUV is a low- 
cost robot designed for mine detection. One of the research group's goal is to demonstrate that 
autonomous underwater robots are a solution which can provide underway units the ability to search 
areas for mines and obstacles from a safe distance. Figure 1.1 shows the Phoenix AUV deployed 
during in-water testing. 

In addition to in-water robot testing, the NPS has a fully operational virtual environment 
which is used for simulation-based design (SBD). This provides a low-cost development environment 
for many possible robot technologies, reducing both project cost and time to deliver operational 
devices. The virtual environment gives researchers the ability to thoroughly test future devices in 


diverse operating conditions. 





Figure 1.1. The Phoenix AUV deployed for in 
water testing (Brutzman, 1998). 


B. MOTIVATION 


Virtual environments provide a realistic arena for the testing and development of future 
vehicle technologies. It is necessary to ensure that simulations are physically based and accurate in 
order to support proper testing and development. This type of simulation-based design (SBD) can be 
used to develop the tools that the military will need to transition to the next century. This thesis 
presents solutions to previously unsolved underwater robot challenges, new capabilities in mine 
warfare and advancements in SBD techniques. 

1. Mine Warfare 

The NPS AUV research group has been striving with great success to provide a low-cost robot 
solution to mine detection and classification since 1986. The next logical step is to provide a sound 
method for the forward deployment and retrieval of AUV technology. Demonstrating that an AUV ` 


can be released and recovered underway "closes the loop” for AUVs by providing fully deployable 


technological solutions. 


Submerged vehicle launch has a relatively easy solution. Submarines have been launching 
various objects through torpedo tubes since World War I. While some modifications to existing tube 
hardware may be required, a clear path to the launching solution exists. The most difficult problem 
for submarine deployment is recovery. Recovery is essential for mission data analysis and AUV re- 
use. This work provides an important missing link: autonomous vehicle control through turbulent 
water flow while docking. This new capability provides submarines the potential to effectively engage 
in counter mine warfare through deployment of recoverable AUVs. 

2. Platform Independence 

A second motivation for this research is commonly referred to (in the computer science 
domain) as platform independence. In the context of the problem at hand it is taken to mean providing 
the ability to simulate complex virtual environments on whatever computer resources are available, 
regardless of make, architecture, or operating system. As computational power has increased in the 
recent past, complex simulations are no longer limited to users with high-end graphics workstations. 
Personal computers have the capacity to manage applications that were previously unavailable. 

The vision this work has pursued is m in which anyone anywhere with network connectivity 
can view and actively participate in complex simulation exercises. We are attempting to build a closer 
link between those involved in design and testing and the end user of technology. While the platform- 
independence issue is not directly related to solving torpedo tube docking of an AUV, its importance 
cannot be underestimated. It drives home the point that simulation for spatial awareness can be used 


anywhere. 


C. OBJECTIVES 


The objective of this research is to design a method of simulating AUV control in a true ocean 
environment in order to accurately test and develop algorithms for moving torpedo tube recovery. To 


achieve this goal there are several sub-problems to address: 


> Wave motion must be accurately simulated for numerous sea states. This is significant 
due to the unpredictability of the ocean environment. For a prototype AUV to be fully 
tested, all possible sea conditions must be available. 


> Foreign-body-induced flow forces must be depicted as realistically as currently 


E 


possible. These types of forces pose the most difficult problems to the development of 
control algorithms for several reasons. First, they are extremely dynamic. The state of 
flow forces are continuously changing and influenced by many independent factors, 
many of which are not yet completely understood. Second, they occur in the regions 
where robot control is most crucial, i.e. the areas where a control failure could cause 
devastating damage to both the robot and recovery vehicle. 


Extensibility needs to be considered when modeling flow fields. While a significant 
amount is known about the nature and behavior of complex fluid flow, there is still 
much to be discovered. By creating a methodology which allows for the upgrade of 
simulation flow field data as the science of fluid dynamics advances, the accuracy and 
lifetime of the virtual world is enhanced. 


Refinement of the equations of motion is also necessary. The ability to model a 
vehicles behavior based on its size and shape as forces act upon it becomes another 
concern when trying to ensure the behavioral accuracy of such an environment. In 
previous versions of the Phoenix AUV’s Virtual World the equations of motion were 
based solely on a cylindrical body shape. 


The source code for the Phoenix AUV Virtual World is distributed openly. 
Unfortunately, due to the computational complexity of such a model its use has 
previously been feasible for only those users with high-end Silicon Graphics | 
workstations. With the capabilities of personal computers rapidly increasing and the 
introduction of platform-independent languages (such as Virtual Reality Modeling 
Language (VRML) and Java) it has become possible to move this simulation into the 
platform-independent domain. To this end a platform-independent implementation 1s 
also provided. 


THESIS OUTLINE 


This chapter describes the background, motivation, and objectives of creating a virtual world 


which accurately models the ocean environment. Chapter II discusses the background of the 


Autonomous Underwater Vehicle (AUV) at the Naval Postgraduate School (NPS) including its 


purpose, history and related research projects. Chapter III evaluates the goals of this work providing a 


clear and concise problem statement. Chapter IV provides in-depth discussion of design 


considerations and hydrodynamics modeling related to the simulation. Chapter V addresses changes 


required to the AUV execution level, both hardware and software, needed to equip the vehicle so it 


can successfully operate in such an environment. Chapter VI and Chapter VII describe the simulation 


„Де 


results found in this research, including run-time performance, simulation limitations and robot 
control/sensor upgrades. Chapter VIII presents conclusions, research contributions and 


recommendations for future work. 





II. RELATED WORK 


A. INTRODUCTION 


The technology involved in virtual environment development and robot simulation 
encompasses many disciplines. While these two tasks seem to be well suited for one another, the 
fields of study that produce the theories employed by each are vastly different. This chapter looks at 
the important areas evaluated for use in this research. The topics range from cutting-edge computer 
graphics to mechanical engineering practices that have been around for many decades. Nevertheless, 
all of these techniques are needed to create the solution to this difficult problem. 

Specific related-work topics examined in this chapter include Phoenix AUV hardware and 
software, underwater virtual world modeling, distributed control, the Virtual Reality Modeling 
Language (VRML), the Java programming language, the Distributed Interactive Simulation (DIS) 
protocol, the DIS-Java-VRML project, and Computational Fluid Dynamics (CFD). 


B. PHOENIX AUV 


An Autonomous Underwater Vehicle (AUV) is a self-contained underwater robot typically 
combining a multitude of sensors and controllers. The Phoenix AUV is an incarnation of this type of 
robot developed to demonstrate the abilities of a low-cost autonomous platform. The Phoenix 
architecture can be broken down into two major categories: hardware and software. 

1. Hardware Architecture 

The Naval Postgraduate School’s (NPS) Phoenix AUV is a complex robot, comprised of a 
single water-tight compartment which contains various motors, controllers, servo-amplifiers, and 
computers. The internal component layout is shown in Figure 2.1 . Figure 2.2 shows the an external 
view of the hardware layout. 

The main processing power inside the Phoenix comes from two computers. A Gespac M68030 
is used to run the execution level software while a Sun Voyager Sparc 5 Workstation runs the tactical 
and strategic level software (Brutzman, 1998). The specifics of each software level will be discussed 


in the following section. The Gespac computer runs the OS-9 operating system allowing for use of 


qe 


real-time multitasking functions when controlling the vehicle devices (Byrnes, 1993). The Sun 
Voyager 5 runs SunOS 5.4. These computers are networked together via an Ethernet inside the 
vehicle. This allows for the machines to easily communicate. It also has advantages in terms of 
remote monitoring. The Ethernet optionally provides Internet connectivity to the boat through a 
tether. The tether can be used to monitor each process, collect data, or to intervene when an 


operational fault occurs. 
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Figure 2.1. Internal view of the Phoenix AUVs component layout 
(Marco, 1996). -8- 


Other interesting pieces of gear include two high-resolution sonar units, a Global Positioning 
System, and an inertia] navigation package. The sonar units provide excellent detect and classification 
abilities. They have 1 cm resolution out to a maximum range of 30 meters. Additionally, the ST725 
(725 KHz) has a 1° wide by 24° vertical beam, and the ST1000 (1 MHz) a conical beam of 1° 
(Brutzman et al, 1998). All of these devices are used to provide a fully autonomous robot with 


significant operational and navigational capabilities. 
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Figure 2.2. External view of the Phoenix AUVs component layout (Marco, 1996). 


2. Software Architecture 

The software architecture of the Phoenix AUV is a tri-level design called the Rational 
Behavior Model (RBM). The RBM architecture consists of three separate software layers, each layer 
having its own functional requirements, implementation restrictions, and component interfaces 
(Byrnes, 1993)(Byrnes, 1996)(Marco, Healey, McGhee, 1996). RBM divides robot control into 
functional blocks which mimic those of a submarine operational structure. Thus the use of RBM in 
the NPS vehicle is well suited to the thinking patterns of students involved in the project. 

The RBM divides responsibilities into areas of open-ended strategic planning, soft real-time 
tactical concern, and hard real-time execution level tasks. Figure 2.3 shows the relationship between 


strategic, tactical and execution levels in the RBM. 


Strategic Mh ssion Commanding 
Logic Officer 


Officer of the 
Deck/Watch 
Officers 


‘Tactical Vehicle 
Behaviors 


E h: Hardware 
xecution — ο VE 





Figure 2.3. The Rational Behavior Model Architecture Pyramid (Holden, 1995) 


The execution level provides the interface between software and hardware. It is designed to 


meet all of the systems hard real-time requirements. The execution level is responsible for the 
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underlying stability of the vehicle, the control of individual devices, and providing data to the tactical 
level (Byrnes, 1993)(Byrnes, 1996). In terms of an underway watch team organization, the execution 
level performs the tasks normally assigned to individual watchstanders. 

The level of command above the watchstanders in the underway watch team is the Officer Of 
the Deck (OOD). The OOD’s responsibilities are concerned with the tactical picture: what individual 
tasks need to be completed to reach a goal. In the RBM this functionality is contained in the tactical 
level. The tactical level does not operate on hard real-time deadlines, rather it operates in terms of 
discrete events (Byrnes, 1993)(Byrnes, 1996). It provides a software level that interfaces with both the 
execution and the strategic levels, thus giving strategic level indication of vehicle state and completed 
tasks, and execution level commands. 

The highest level of the RBM 1s the strategic level. This portion corresponds to the role of a 
commanding officer. It is not concerned with the specifics of task completion. Instead the issues that 
the strategic level monitors are the completion of mission goals. Inside the strategic level resides the 
mission specification. Through symbolic computing it uses a set of rules coupled with an inference 
engine to direct (and respond to) the tactical level (Byrnes, 1993)((Byrnes, 1996). 

The RBM is a complex architecture, but it greatly simplifies AUV design and operation 
through appropriate levels of abstraction. By setting clear boundaries between areas of responsibility, 
RBM enables robot control to be defined by separate applications with predefined interfaces. RBM 
also allows naval students, who are intimately familiar with an at-sea watch structure, to apply real- 
world experience to complicated control problems. Using an architecture designed for both robot and 


human requirements has been a crucial advantage. 


C. PHOENIX AUV VIRTUAL ENVIRONMENT 


Development of an AUV poses a number of unique problems. Chief among those problems is 
the fact that during the actual in-water testing of robot hardware and software, it is often impossible to 
observe or communicate with the vehicle. Analysis is typically limited to post-exercise data review 
alone. This situation confronts designers with a difficult development process. Physical remoteness 
and inability to observe effectively takes away one of the human mind's greatest strengths: the ability 


to visualize. To overcome this problem, a virtual world was developed which models salient 


ge 


characteristics of the ocean environment from the robot's perspective (Brutzman, 1994). This 
effectively puts humans back into middle of the testing and development loop, and allows developers 
to visualize robot behavior under diverse conditions. 

The virtual environment provides an area of underwater terrain in which testing and 
development can be observed. Figure 2.4 is a recent view of the underwater world showing all of the 
major objects that are contained, including Phoenix at the surface just right of center. The 
implementation of the Phoenix AUVs virtual world is broken into three major sections. One portion 
represents the physical side of the operating environment, a second is robot software (and optionally 


hardware), and a third provides an interactive3D graphics window into the virtual environment. 





Figure 2.4 - The Phoenix AUV Virtual World. 
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The most complex of the modules which comprise the virtual environment is the one which 
models the vehicle hydrodynamics. Inside this program all aspects of vehicle motion are considered. 
Using a Newton-Euler approach to the derivation of the six degree-of-freedom equations of motion 
(Brutzman, 1994)(Healey, 1992), the program provides a very accurate rendition of the environment. 
The dynamics program takes input from the vehicle, describing the state of all of its devices, and 
calculates in complete detail the responses the vehicle 1s expected to receive from the environment. 
Other physical models includereal-time sonar detection, Global Positioning System (GPS), and 
acoustic navigation. 

Another component of the virtual environment is the AUV software. This code performs the 
task of controlling all of the devices associated with the AUV, including propellers, thrusters, sonars, 
inertial navigation systems and any other hardware installed on Phoenix. This execution level control 
is coupled with the more sophisticated robot intelligence provided by the strategic and tactical levels. 
Communication is conducted through all levels of the RBM architecture to determine how to deploy 
each one of these devices. After determining the state of each sensor and effector, the execution level 
sends out the commands placing them in the appropriate state. Since in the virtual simulation the 
devices are typically not physically present, they are positioned via telemetry vector message 
interchange with the dynamics program. The effects of all the devices are determined by the dynamics 
program models, and then proper responses are sent back to the execution level software. This query- 
response interchange is incorporated into the sense and act phases of the execution level's sense- 
decide-act cycle. This design architecture enables the robot to run and respond to various stimuli in 
the same manner in the virtual world as in the real world, since the robot software in each case 1s 
identical (Burns, 1996). 

The final portion of the virtual environment gives the user an interactive 3D graphics window 
into the environment. Referred to as the viewer, this program allows observation of all aspects of the 
simulation. Virtual representations are provided to indicate the robots employment of each sensor and 
effector. This visualization has repeatedly been shown to be essential to the development process. 


Figure 2.5 shows the animations associated with the robots use of thrusters and propellers. 
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Figure 2.5. Phoenix AUV in the virtual environment 
demonstrating use of thrusters and main motors. 


This type of visual representation also gives some intuition into how the AUV employs its 
sonar assets. Sonar visualization was used to implement and refine a control algorithm which enables 
the Phoenix AUV to detect and classify objects in the water (Davis, 1996). In the case of a detected 
tube like object the algorithm was further enhanced to allow the vehicle to safely begin entering the 
tube. Figure 2.6 is a screen capture of this type of mission being executed in the virtual environment. 

All of these components are networked together to provide an integrated development 
environment. Multiple simultaneous viewers are enabled via use of the Distributed Interactive 
Simulation (DIS) protocol (IEEE, 1993)(IEEE, 1994a)(IEEE, 1994b). The position, orientation and 
state of the vehicle are multicast across the network via Entity State Protocol Data Units (ESPDU). 
The viewer application listens to the network for these packets, extracts the information from them, 
and incorporates it into the scene rendered in the virtual world. Decoupling graphics viewers from 
robot software and virtual world models provides a scalable approach that permits multiple 
researchers to evaluate robot mission progress. 

The versatility of the virtual world was further demonstrated by its use for prototype modeling 
of an optical sensor, used for AUV guidance and control without sonar, while docking with a 


stationary torpedo tube (DelTheil, 1997). 
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Figure 2.6. Phoenix AUV Using Sonar to detect and Classify a Torpedo 
Tube (Davis, 1996). 


A virtual environment provides an outstanding arena for robot testing and 
development. It affords system engineers the opportunity to observe equipment operation in a safe 
controlled environment. This type of technological advance is a large step forward for the underwater 


robot community. 


D. DISTRIBUTED ANALOG/DIGITAL CONTROL DEVELOPMENT 


Computing power has been increasing at an amazing rate. The average lifetime for new 
technology in the computer industry is only nine months, with processing power increasing by an 
order of magnitude every two years. One area in which similar advances are being made is 
networking. These advances have come in transfer rate increases and reliability improvements. This 
allows system designers to leverage the network (and all the resources attached to it) as additional 
assets. 

The network provides an unlimited number of additional resources to any computing system. 
Similar advances are also being made in control technology for data acquisition systems. Smart 


controllers present the opportunity to create autonomous device controls which can monitor device 
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operation, output necessary data readings, and react properly when provided operational commands 
from remote stations. One company leading the way in this field is Echelon. They have developed a 
series of programmable devices which all communicate over a network using a proprietary network 
protocol called LonTalk (Young, 1998). 

Use of small specialized processors can give any system significant performance 
improvements. By offloading portions of specialized control code a central monitor application 
becomes more concise, allowing it to execute more quickly and efficiently. It also adds to system 
robustness. No longer will a single fault halt operation. Other devices not affected by a single control 
board failure will continue to operate normally, leaving the monitoring application to adjust for a 
single device failure. 

Distributed control is the direction in which many data acquisition systems are moving. 
Systems as diverse as elevator control systems and high-voltage air conditioning systems all gain 
from distributed control. This technology can also give the Phoenix AUV execution level a welcome 


upgrade (Young, 1998). 


E. VIRTUAL REALITY MODELING LANGUAGE (VRML) 


As the Internet continues to expand and gain in popularity, many new technologies are being 
developed to utilize this medium. In the past, browsing web pages has been restricted to two 
dimensions. The Virtual Reality Modeling Language (VRML) brings three-space to the Web. 

VRML is an interpreted language that allows developers to create content-rich three- 
dimensional (3D) worlds which can be viewed across the Internet inside a web browser. At its core 
VRML is a specification for describing 3D worlds through a text-based file format (Ames, 

199 7 ( VRML, 1997). 
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SVRML V2.0 utf8 


Group { 
Children [ 
Viewpoint { 
description Initial view 
position 6 -1 0 
orientation ο ο 57 
} 
Shape { 
geometry Sphere { radius 1 } 
appearance Appearance { 
texture ImageTexture { 
TUE L earth-topo.png 
ο 
Transform ( 
translation 0 1225 
rotation О 0 m57 
Children [ 
Shape { 
geometry Text { 
string i" Helle ποσα] 
} 


appearance Appearance { 
material Material { 
diffuseColor 0.1 0.5 1 


}}} 
] 


Figure 2.7. VRML source code hello_world.wrl taken from (Brutzman, 
1998a). 


While VRML is a powerful object description language, it is also a simple language to learn. 


The novice can quickly learn enough to develop his first program. Figure 2.7 is a programming listing 


for the basic “Hello World” program found in so many programming texts (Brutzman, 1998a). The 


results of this small scene description are displayed in Figure 2.8. This demonstrates just how simple 


VRML makes 3D authoring. 
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Figure 2.8. Output of Hello. world.wrl. 


The power of VRML is its ability to create dynamic environments. It fully supports animation, 
user interaction, and advanced object behaviors through scripts (Hartman, 1997). After describing 
objects inside a world a developer has many options regarding how to use those objects. Animation 


can be performed through predetermined routes, execution of scripts, or dynamically using outside 
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applications to manipulate objects inside the world. The overall affect is the creation of portable 
virtual environments which are visually pleasing and truly interesting. The greatest promise of VRML 
with respect to this project is the possibility of 3D visualization of AUV missions using any web 


browser. 


F. JAVA 

Java is a fully functional programming language which was first released in 1995 by Sun 
Microsystems. It is a solidly engineered language that was created with many ideal design goals in 
mind. Table 2.1 gives the key features as described by the authors of Java (Cornell, 1997). The key 
features of interest related to the work described in this thesis are that it is architecture neutral, object 
oriented, and portable (Cornell, 1997). 

Java is an architecture-neutral language. What this means is that when a Java program is 
compiled the compiler creates a neutral file format that contains byte codes of the compiled program. 
These byte codes can then be executed on many different processors with the Java run-time 


environment present. The run-time system interprets the byte codes and translates the information into 


native machine code for execution. 










Java MEM va Design Goals | on Goals . Functionalit of Concern for this Thesis | 
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Table 2.1. Design goals of the Java programming language, contrasted with thesis goals. 


The object-oriented programming paradigm provides numerous useful characteristics. Java 
fully supports data hiding, encapsulation, inheritance and code reuse through this object-oriented 
approach. This type paradigm focuses on the data being manipulated by an application instead of how 
each step of the manipulation takes place. It gives the developer the ability to write code once and use 
it many times in many different applications. 

Portability brings Java to the Web. There are no implementation-dependent aspects of the Java 
specification (Cornell, 1997). This means that the binary data is stored in a fixed format which 
eliminates the problems of running code on various platforms. Through this type of implementation 
and the use of standard libraries which define portable interfaces, Java byte codes can be retrieved 
across the Internet and run on local platforms, independent of the machine architecture. 

As the world wide web continues to increase in popularity, Java is positioned to be the 
language of choice. Its well-designed class library provides all the functionality required to develop 
professional applications. These applications can be easily distributed via the Internet and run on any 


platform which has the Java run-time environment present. 


G. DISTRIBUTED INTERACTIVE SIMULATION (DIS) PROTOCOL 


The Distributed Interactive Simulation (DIS) protocol describes a standard of communications 
between entities in distributed simulations (IEEE 93, 94a, 94b). It is well suited for general usage in 
networked virtual environments due to the standardization of object interactions. This allows many 
users in remote locations to view or participate in a simulation as long as the standard object interface 
is followed. 

Information is passed between entities through the use of protocol data units (PDUs). Figure 
2.9 demonstrates the architecture of a distributed simulation using DIS. There are 27 different types of 
PDUS defined for use. Each one addresses a different possible interaction between entities. Types of 
PDUS range from the most common Entity State PDU, to the more rarely used Electromagnetic 


Emission PDU. The Entity State PDU is the primary PDU used, containing information about an 
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entity's position, posture, linear and angular velocities and accelerations. It is sent across the network 
by an object whenever one of the its entity state parameters changes by a threshold amount or a 
designated time period has expired. All other entities that are concerned with the position information 
of the sending entity will listen for the PDU and upon receipt will integrate that information into the 
rendered scene. 

Networking provides a significant advantage when working in virtual environments. It allows 
objects which are being operated on remote workstations to be viewed locally. In a complex world 
objects can be offloaded to idle processors while they are rendered by the local machine. This type of 


network interaction is possible through the standards defined by the DIS protocol. 


Simulation 1 Simulation2 Simulation 3 


Network 





Figure 2.9. Network Connectivity of a DIS simulation. 


Н. DIS-JAVA-VRML 


In an effort to bring large-scale distributed simulations to the personal computer domain a 
working group has been formed to integrate DIS with Java and VRML. A VRML Consortium 
(www.vrml.org) working group is a technical committee which tries to solve specific technical 
problems. The DIS-Java-VRML working group was chartered with numerous goals aimed at making 


these technologies work together. 
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Some specific objectives of the DIS-Java- VRML working group include completing a freely 
available Java implementation of the DIS protocol, producing a set of references and recommended 
practices for mapping between DIS and VRML worlds, create various DIS utilities in Java, and to 
also create some standard physics and math libraries to be used in these simulations. More 
information for regarding the working group can be found at [http://www.stl.nps.navy.mil/dis-java- 
угт! |. 


Browser 


DIS yn VRML 
Application Bridge Plug-in 


Network 
Figure 2.10. DIS-Java- VRML interaction layout. 





The overall layout of a simulation using the DIS-Java-VRML library is quite unique. The 
library handles the interactions between the network, browser, and VRML plugin. Figure 2.10 
outlines the interactions handled by the library. 

Combining the capabilities of DIS, Java and VRML can quickly allow developers to create 


content-rich networked simulations that are available to anyone with access to the Internet. The 
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possibilities of simulation content and complexity are endless. With access via the Web simulations 
can be run anywhere in the world regardless of the locality of participants and simulation monitors. 
This integration truly adds new dimensions to virtual environment use. It continues to move the Web 


into three-space. 


I. COMPUTATIONAL FLUID DYNAMICS (CFD) 


Computational Fluid Dynamics (CFD) is a field of study concerned with the prediction of 
fluid motion about bodies of arbitrary shape. Supercomputers are typically used to solve numeric 
approximations that describe the fluid flow. 

Looking more closely at the term CFD, this branch of science is considered computational 
because of the use of high-speed computing resources. The fluid flows are typically modeled and 
analyzed using large sets of Navier-Stokes partial differential equations. Solving these equations for 
specific fluid-flow cases is computationally intense because no closed-form solutions exist, except in 
trivially special cases (Scientific Computing Group at Indiana University, 1998). Thus any given 
problem may take days of computational cycles to solve. Solution of CFD problems are generally 
considered to be among the grand challenges of supercomputing. 

CFD also refers to the analysis of fluids. Fluid refers to anything that isn't a solid, thus both 
air and water are considered. A more technical definition classifies fluids “as any substance which 
cannot remain at rest under a sliding, or shearing, stress (Scientific Computing Group at Indiana 
University, 1998)." 

Finally, CFD dynamics refers to the study of objects in motion. In dynamics one is concerned 
with an objects motion and the forces associated with that motion. This is very different from 
kinematics, which is concerned with the relationships of motion quantities regardless of the forces 
induced by that motion (Healey, 1998). Kinematics models are typically less realistic than dynamics 
models. In general the resolution of kinematics models are demonstrably inadequate for AUV motion 
prediction. 

Overall, CFD is a numerically intensive science. Solutions to CFD problems are extremely 
complex and often require the most advanced computer systems to solve. Thus research in this field is 


extremely important, providing the basis for understanding complex flow interactions. From there 
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simpler representations of flow interactions can be created which provide a general model for testing. 
The approach taken by this thesis completely avoids the field of supercomputing CFD, and instead 
seeks PC-based or workstation-based solutions which produce imperfect but adequate results in 


realtime for human operator and robot use. 


J. SUMMARY 


Many disciplines are needed to complete any complex project. The basis for the solution to the 
problem of torpedo tube docking of the Phoenix AUV epitomizes that notion. Simulation-based 
research and design draws from the newest available technologies. While the environmental forces 
which must be modeled in this type of simulation have been around since the beginning of time, only 
recently has technology been created to help man solve problems in many disciplines. A broad level 
of knowledge must be used to arrive at a correct solution when considering large and complex 
problems. 

This chapter presented an overview of many topics related to the solutions presented in this 
thesis. The Phoenix AUV hardware, software and underwater virtual world modeling were discussed 
because they provide the basis for the testing presented. Other areas such as distributed control, the 
Virtual Reality Modeling Language (VRML), the Java programming language, the Distributed 
Interactive Simulation (DIS) protocol, the DIS-Java- VRML project and Computational Fluid 
Dynamics (CFD) also play a role important roles in solving the problem of torpedo tube recovery. 


While no one topic provides all answers, a combination provides a well-rounded solution. 
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III. PROBLEM STATEMENT 


As the mission of the United States Navy continues to focus on littoral warfare, the 
importance of mine warfare becomes more apparent. Mine warfare has historically been one of the 
most difficult tasks performed by naval units. The majority of the tactical burden has often fallen on 
submarines since their operational areas often coincide with the areas of most value to enemy forces. 
One outstanding tool for mine detection is an Autonomous Underwater Vehicle (AUV). This type of 
robot can be used to scour forward areas using high-frequency sonars and global positioning systems 
(GPS) to detect and neutralize mines, easing the burden of mine detection on all forward-deployed 
units. 

The majority of technical issues preventing this type of AUV deployment have been solved. 
The only problem remaining before this type of vehicle deployment can be executed is the vehicle 
recovery system. Vehicle recovery poses many difficult problems. The evolution itself is very 
dangerous for both the recovering submarine and the AUV. Even the smallest mistake can place the 
submarine at great risk. If the recovery does not run smoothly, damage can range from complete loss 
of the AUV to a breach of the water-tight integrity of the recovering submarine, thus threatening the 
safety of her crew. There is an intolerably small margin of error. 

In an effort to conquer the unresolved issues associated with mine warfare, the Phoenix AUV 
has been created as a research and development platform. It is used to test the newest equipment on 
the market and to develop control algorithms which employs this equipment most effectively. Even in 
stand-alone development the risk of vehicle loss is very high. While robot code is written with safety 
of the vehicle in mind, robot testing is inherently dangerous. For that reason a virtual environment 
was created that is used to test software and hardware prior to in-water testing (Brutzman, 1994). 

A virtual world provides an exceptional resource for the testing and development of AUV 
technology. The difficulties associated with the underwater environment are numerous and complex. 
In order to properly validate the results from such a world, one must accurately model the physics 
associated with the vehicle, its submerged hydrodynamics characteristics, and the environment. 
Environmental effects such wave motion, currents, and flow forces created by bodies moving 


through the water can cause significant variance in the testing environment. The current version of 
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the Phoenix AUV Virtual World includes steady-state ocean currents, but does not take into account 
the localized environmental effects of waves and body-induced flow forces. 

In an effort to provide this type of realistic simulation environment, the effects of 
environmental factors have been completely integrated into the hydrodynamic simulation. This work 
provides a sound real-time simulation of these complex factors using physically based models. The 
problem is broken down into wave motion effects, body-induced flow fields, and AUV motion 
control. Each one is thoroughly analyzed and realistically simulated in real-time through the 
algorithms developed. 

The result of this research is a Virtual World which accurately depicts the ocean environment. 
It can be used to test and develop the control algorithms required to operate an Autonomous 
Underwater Vehicle in any situation without risk. This environment thus provides a safe and 
physically accurate arena in which the problem of torpedo tube recovery can be carefully examined. 

Another issue evaluated in this work is platform independence. As research and development 
money becomes scarce, the availability of high-end graphics workstations is also becoming rare. With 
the advent of platform independent languages such as Virtual Reality Modeling Language (VRML) 
and Java, the ability to run complex three-dimensional (3D) simulations on personal computers has 
arrived. In addition to providing a realistic virtual environment for development of new technology 
this work strives to make that simulation available for anyone to use. By using web-based 
technologies anyone can view and interact with the simulation and development process, further 
advancing the marriage between developer and end user. 

The principal problem addressed by this thesis is that of torpedo tube recovery of the Phoenix 
AUV. It employs a physically based virtual environment to simulate the forces encountered during 
such an evolution. The goal is to provide an overall solution to the problems associated with torpedo 


tube recovery through simulation-based design (SBD). 
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IV. HYDRODYNAMICS MODELING 


A. INTRODUCTION 


This chapter presents the theory behind the implementation of cross-body flow in the Phoenix 
virtual environment. The problem of modeling cross-body flow is broken down into several 
components, each of which is analyzed in depth. An overview first outlines the components of the 
equations of motion algorithms with some detail on the individual parts. The high-resolution 
buoyancy model is described as the basis for modeling flow forces on the AUV. Wave-motion 
simulation is examined in detail, followed by body-induced flow simulation and square hull versus 


round hull adjustments to the equations of motion. 


B. OVERVIEW 


Virtual environments are a very useful tool in the research and development process. Their use 
can provide sound simulation-based designs. The ability to test and redesign during development 
allows for relatively easy correction of design flaws and can save valuable time and money in the 
process. Nevertheless any simulation is only as good as the physical model it 1s based on. A virtual 
ocean environment which fails to address the physical forces that are present in the real ocean 
provides little insight during development, perhaps guaranteeing the failure of the project. 

The elements of nature must be completely integrated into any simulation environment if it is 
to be used as a true test platform. Additionally, the ocean environment has unique characteristics 
which make its simulation more complex. Factors such as buoyancy, wave motion, and body-induced 
flow forces are among the most computationally complex to model. They are all significant and 
cannot be overlooked when developing a true simulation environment. Figure 4.1 shows the overall 
flow of information within the hydrodynamics model. The separate sections indicate areas of code 
that handle specific calculations which are calculated during each time step. The overall 
hydrodynamics model is described in (Brutzman 94a, 94b, 98). The simple buoyancy model is 
described in (Bacon, 96). This thesis implements the shaded blocks in Figure 4.1. Throughout the 
following discussion of theoretical basis, simplifications were made to ensure true real-time 


performance of the simulation. Assumptions are made when the effect of their simplification do not 
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effect the accuracy of the model, while providing performance improvement. Table 4.1 provides a 
summary of assumptions which will be presented and justified later in the chapter. This chapter 
provides the theoretical basis for a high-resolution buoyancy model, physically based wave motion 
simulation, external submarine body-induced flow field simulation, more precise modeling of square 


hulls versus round hulls, and refinements to the equations of motion (EOM). 


Assumptions 


| Wave motion simulation 1. Wave motion effects vehicle position and orientation are due to 


the movement of water across the vehicle body as waves move past. | 


2. The length of the Phoenix AUV is small enough that measuring 
wave height above the vehicle at '2 foot increments gives a realistic 
representation of the wave forces felt by the vehicle. 
Environmental Factors 1. The effects of ocean current are felt by both the AUV and the 
submarine, thus the relative motion caused by steady-state current 


can be ignored locally. 


2. The time variation of environmental factors such as change in sea 
state is slow and can be ignored for the duration of a docking 
evolution. 

AUV docking approach 1. The AUV will always approach the submarines torpedo tube from 


aft in order to maintain stability and minimize risk of collision. 


2. The AUV approach course will be such that it never passes 
through the turbulence caused by the submarines propeller(s). 
Flat-plate fluid flow theory | 1. The submarine is large enough (when viewed from the AUV) that 


the hull appears as a flat plate. 


| 2. The majority of drag across the submarine as it moves through the 





water is pressure drag vice skin friction drag. 


Table 4.1. Overview of assumptions made to implement wave motion and flow models. 
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Begin Integration of Equations of Motion í 
If ( 


Low resolution buoyancy model 
u Ππ 


High resolution buoyancy model 


Wave force calculation model x 


| Body-induced flow field model 
Cross-body drag integration for square/round hull vehicle 


j 


Final calculation of EOM for current time-step 





j End Integration of Equations of Motion. 


Figure 4.1. Flow of information within hydrodynamic model of the Phoenix AUV 
virtual environment. 


C. BUOYANCY MODEL 


Simulation of ocean-going vehicles poses many unique problems. They differ from land- 
based vehicles by exhibiting six degrees of freedom (DOF) in their movement. They primarily differ 
from air vehicles (which do move in six degrees) with respect to buoyancy forces. Buoyancy forces 
differ significantly from the lift experienced in air vehicles. One major difference between these types 
of forces in the modeling and simulation context is fairly straight forward: for an air vehicle, once the 
dimensions are known, the lift force exerted on the plane is proportional to air speed. From these 
forces one can easily calculate position and orientation. In the sea-going vehicle domain, however the 


dynamics model isn't as simple. Vehicle buoyancy is a major contributor to determining vehicle 
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position and orientation, and this quantity is truly dynamic when at the surface. Buoyancy varies 
based on the amount of water displaced at that particular time step, which is an instantly changing 
irregular 3D volumetric integral. Therefore, in order to maintain real-time response, the calculation 
must be optimized and flexible. This is especially important in the underwater domain since buoyancy 
determines whether the vehicle can maintain depth or sink. 

The original virtual world hydrodynamics model only handled neutrally buoyant vehicles 
(Brutzman, 1994). A later refinement estimated buoyancy using box approximations for volume and 
center of buoyancy (Bacon, 1995). This approach provided reasonably accurate simulation when fully 
or partially submerged, but may be insufficient when the submersible is continuously operating on the 
surface or at shallow depths in a surf zone. In this thesis, a high-resolution model is presented that 
precisely approximates volume and center of buoyancy by evaluating the submersible over 15 
separate slices. Each slice has its own buoyancy (and center of buoyancy) that are approximated and 


calculated every time step. Figure 4.2 shows this type of partitioning applied to the Phoenix AUV. 





Figure 4.2. AUV broken into buoyancy model slices. 


This buoyancy model works well and accurately models vehicle response in a variety of 
surfaced and broached conditions. When submerged, each piece of the AUV retains its full buoyant 


force giving the AUV neutral buoyancy. On the surface, the portions of the boat which are out of the 
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water are subtracted from the net buoyancy giving an approximately correct value for that condition. 
Additional impacts of buoyancy on a shifted center of buoyancy are calculated piecewise and then 
summed, using the same computational model provided in (Bacon, 1996). Figure 4.3 graphically 


represents the buoyancy model from (Bacon, 1996). 


Righting Moment 


Original CB 





Figure 4.3. Effect of submerged body exiting water on center of buoyancy (Bacon, 
1996) 


The only condition not considered previously was the effect of ocean waves on vehicle 
buoyancy. Since the model worked so well for the boundary conditions it seemed appropriate to 
extend it by adding the needed functionality to accurately model sea state effects on vehicle motion. 
In order to do so there are several factors to consider and assumptions to make. Issues to address. 
range from what forces are that wave motion produces, how these can be estimated, and finally how 
are they applied to the vehicle to produce an accurate simulation. 

The first assumption to be evaluated applies to the effect wave motion has on the vehicle 
itself. In other words, how do the forces created by passing waves cause the position and orientation 
of the AUV to change? When discussing underwater hydrodynamics one often arrives at the effects 


on a submerged body by multiplying the flow which is present across the body via cross-body drag 


za η 


calculations. This is the proper method to use when the body is moving through a flow. Wave motion 
causes the water surrounding the vehicle to move as a whole. As the wave moves down the length of 
the vehicle the water column surrounding the vehicle is elevated until the crest passes and then it is 
lowered through the trough. The movement of the water column has an effect on the position and 
orientation the vehicle. The cross-body drag present is large enough not to be ignored. With that in 
mind it becomes evident that the most accurate way to simulate wave effects is by evaluating the 
movement of the water column surrounding the vehicle at every time step, and treating that 
movement as piecewise forces, derived from vertical and horizontal velocities. 

Having decided on the proper interaction between wave and vehicle, one must now evaluate 
the interval at which to measure the water column. The length of the Phoenix AUV is relatively small, 
7.3 ft, when compared to the average wavelength of a low sea state. In a sea state of 1 the average 
wavelength is 20 ft. From the buoyancy model already in place calculations are performed for 15 
segments along the body. Continuing this convention for the surrounding water column provides a 
measurement every 6 inches. This accuracy is more than sufficient given the relative size of the 
Phoenix AUV as compared to the wave. This methodology allows the hydrodynamics model to 
calculate a force vector representing the water column surrounding the vehicle at the center of each of 
the 15 body segments. 

The final issue to address when discussing the extension of the buoyancy model to include 
wave effects is how to apply these new force vectors to the vehicle. Superposition of forces is 
performed in a way which is physically accurate and provides a realistic animation in the virtual 
environment. 

As a wave moves along the length of the Phoenix AUV’s body force vectors are created 
representing the direction and magnitude with which the water column is moving at that time step. 
Using these vectors it is now possible to adjust the buoyancy of each vehicle segment to include wave 
motion. For each individual segment the buoyancy and wave force vectors are calculated. Then the 
overall effect on vehicle position and orientation is arrived at by adjusting vehicle buoyancy and the 
center of buoyancy. Vehicle buoyancy and vehicle center of buoyance are determined using the 


(Bacon, 1996) methods. The calculations are based on the equation: 
Buoyancy = pg | f fav 
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where p is the density of water, 


g is gravity, and 


| | |4 V is the volumetric displacement of a submerged (or partially submerged) body section 


at any given time. 

This provides an estimated value for buoyancy which is based on the body segments which are 
actually displacing water. If it is the case that a portion of the vehicle is exposed due to a passing 
wave, that section does not contribute to the vehicle overall buoyancy and the center of buoyancy is 
adjusted. 

The forces created by the flow of the water particles moved by the wave are applied to the 
vehicle via cross-body drag calculations. The wave forces are originally determined in world 
reference frame as velocities. Thus these values must be translated into the local frame and applied 


along the length of the vehicle. The translation is done using the following equation: 


u X -dot 
v |-|Y-dot |R 
W Z — dot 


where u, v, and w are body reference frame velocities, X-dot, Y-dot, and Z-dot represent wave 
velocity in the global reference frame, and [R] is the rotation matrix (Healey, 1998). 

This provides a approximation which is both visually accurate and physically correct. The 
development of an accurate buoyancy model has led to significant advances in the simulation of 
underwater vehicle characteristics. It is now possible to simulate proper vehicle behavior when 
submerged, surfaced, or operating in the surf zone. Taking into account simplifying assumptions 
(such as how wave motion affects vehicle position and orientation) it allows for real-time modeling 
while maintaining a physically correct basis. Through extending this model to include the effects of 
wave motion on vehicle dynamics, another step has been made towards accurately simulating all 
aspects of the ocean environment. One crucial final step remains which is deferred as future work: in- 
water validation of predicted model results. Nevertheless, current behavior is visually and 


algorithmically correct enough to justify development of more robust vehicle control laws. 
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D. WAVE MOTION SIMULATION 


Underwater vehicle design and construction is almost completely preoccupied with 
environmental considerations. The ocean completely surrounds the vehicle, affects the 
slightest nuance of vehicle motion and poses a constant hazard to vehicle survivability. Many 
of the effects of the surrounding environment on a robot vehicle are unique to the underwater 
domain. Vehicles move through the ocean by attempting to control complex forces and 
reactions in a predictable and reliable manner. Thus understanding these forces is a key 
requirement in the development and control of both simple and sophisticated vehicle 
behaviors (Brutzman, 1994). 


With this insight one realizes that in order to provide an arena for the proper development of 
such a complex robot, the art and science of modeling underwater environmental disturbances must 
be mastered. These effects must be coupled and studied with underwater vehicle underwater control 
and dynamic behavior in order to accurately model reality. 

Environmental disturbances play a significant role in marine control applications. Their effects 
dictate how vehicles are designed, constructed and eventually driven. For these reasons the physics of 
the sea have been studied for many years. The major areas of interest can be broken down into three 
broad categories: wind, ocean currents, and wind-generated waves. 

Each one of these forces is important, having a significant effect on both the novice and 
expert ocean traveler. The wind plays a major role in the design of ocean-going vehicles, but in the 
underwater domain its direct affects are minimal. For this reason the introduction of wind to the 
underwater virtual environment dynamics model is not required. It will be left to those interested in 
surface modeling and simulation to implement wind in their appropriate environments. 

Ocean currents are another environmental disturbance which needs to be evaluated. Any ocean 
navigator recognizes the effects of set and drift. Ignoring their influence can be a fatal mistake. These 
currents are also applicable when discussing submerged vehicles. They exist throughout the world 
and have a large effect in terms of vehicle control. In fact the majority of areas where a robot of this 
type would be employed have significant currents (i.e. harbors or river outlets) and so ocean current 
must be dealt with. 

This work uses two complementary approaches to the simulation of ocean currents. The first 
addresses the local frame of reference and the second the global frame of reference. Locally, the AUV 


is influenced by a set and drift which are present in the area of operation. The direction and force 
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associated with the current is calculated and factored into the position calculation at every time step. 
This provides a very simple and accurate modeling of local currents and their affects on the AUV. 

The driving force behind much of this simulation is to provide an ability to accurately simulate 
the forces an AUV will likely encounter while trying to rendezvous with a submarine in the open 
ocean. For this type of maneuver both vehicles remain in a relatively small area. For example, if the 
entire evolution was to take 1 hour with a submarine at a maximum speed of 3 kt then the total area 
traversed is only 6000 yds. This is a small area when contrasted with the vast expanse of the ocean. 
Thus, while in the global frame of reference there may be many different currents to evaluate and 
apply to vehicles in the vicinity, for our purposes it can be assumed that both the AUV and 
submarine are subject to the same set and drift. This assumption provides a useful advantage. Since 
both vehicles are influenced by an equivalent set and drift the relative motion between the two 
vehicles induced by these currents are insignificant. This result provides additional computational 
simplification: relative motion between the AUV and submarine due to steady-state ocean current (set 
and drift) no longer needs to be calculated. 

Ocean currents are a major factor in both ocean navigation and ocean simulation. For that 
reason the virtual environment developed for the Phoenix AUV fully accounts for the effects of these 
environmental forces. 

Wind-generated waves affect both surface vessels and submersibles which operate at shallow 
depths. The process of wave generation due to wind begins with small wavelets appearing on the 
water surface. This increases the drag force which in turn allows short waves to grow. These short 
waves continue to grow until they finally break and their energy is dissipated. It is observed that a 
developing sea or storm starts with high frequencies creating a spectrum with peak at a relative high 
frequency. A storm which has been blowing for a long time (and has reached quasi-equilibrium) is 
Said to create a fully developed sea. After the wind has stopped blowing, low frequency decaying sea 
or swell is formed. These long waves form a spectrum with a low peak frequency. Wind-generated 
waves are usually represented as a sum of a large number of wave components (Fossen, 1990). 

AS early as 1952 researchers were developing mathematical representations of wind- 
generated wave phenomena (Fossen, 1990). Their efforts laid the groundwork for the definition of a 


wave-field spectral-density function. In addition, a large amount of data has been collected via 
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observations. By comparing observed data with the mathematical formulations it has been concluded 
that the spectral density of the energy spectrum as a function of wave frequency is sufficient to 
describe a wave environment of fully developed long-crested seas (Reidel, Healey, 1997). This 
frequency spectrum can be represented as 
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where « and В аге empirical constants defining the spectrum, g is the acceleration of gravity, œ is the 
frequency, and V is the wind velocity. Equation (4.1) describes a general frequency spectrum which 
can be used to fit many observations. To make this formulation more specific there are several 
alternative values for « and B. One can use the Neumann formula, Pierson-Moskowitz (P-M) formula, 
the Bretschneider formula, or the International Ship Structure Formula to name a few (Fossen, 1990). 
The most common of these is the P-M spectrum. In the P-M spectrum typical values are a = 0.0081 
and B = 0.74. 

Inserting values for «œ, B, and g along with some simplification based on the relationship 
between significant wave height (Hs) and wind velocity (V), a simplified version of the P-M spectrum 


can be arrived at (Reidel, Healey, 1997). Formula (4.2) is the simplified P-M spectrum. 
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Using the P-M spectrum provides the spectral density. This information is used to find the 
wave amplitude, which is needed in order to apply the movement of the water column to the AUV as 
described in section B above. The wave amplitude can easily be represented in terms of spectral 


density as follows: 
А? = 25(0)Ло (4.3) 


Here A is the amplitude and Ao is the difference in successive wave frequencies (Еоѕѕеп, 1990). 


From this equation the amplitude of a wave of interest to the position and orientation calculations of 
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the AUV can be arrived at. From here it is necessary to compute the value of wave amplitude at the 
prescribed intervals along the vehicle body. Calculating and combining these many values quickly 


becomes computationally expensive. The final formulation for this approach to wave simulation is 
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where t is time in seconds, freq is wave frequency in radians per second, À is wavelength in ft, and dx 
is the distance along the vehicle body. 

As indicated by the above derivation, wave spectra are complicated and computationally 
expensive. It is difficult to perform this type of analysis as part of a real-time simulation. Luckily the 
diligence and hard work of researchers over the past 45 years alleviates the computational burden 
through published data tables for various wave spectra. These tables are the result of countless hours 
of hard work and provide a solid basis for wave simulation. Table 4.2 is an excerpt from a table found 
in (Bertaux 1976). It gives all the pertinent data required to approximate the P-M spectrum in any sea 
State ranging from 0-9. The fields of interest are significant wave height, frequency, and wavelength. 
With this information the state of a wave at any given time step along the body of the AUV can be 


calculated. 


Es 


Sea State Average Average Period Average Wave Minimum 
Significant Wave (seconds) Length (ft) Duration (hours) 
Height (ft) 





Table 4.2. Characteristics of a fully arisen sea. Excerpts taken from (Bertaux, 1976). 


Having this data in the form of a lookup table at program run time gives the ability to 
dynamically apply the affects of a fully developed sea state to the vehicle. The computational 
advantage gained is tremendous. Equation 4.1 shows how a single wave can be applied to one section 


of the vehicle using the lookup values. 
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(4.5) 


where, Hs is the significant wave height, t is бте, А 15 wave length, and dx is the distance along the 
AUV body. This allows the instantaneous height of a wave to be calculated for each segment of the 


AUV body. This height is then transformed into a buoyancy force as previously described in section B 


above. 
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Lookup tables also present the possibility of changing sea state during simulation. Although 
this functionality is currently implemented it is important to point out that sea state cannot change in 
nature instantaneously. Nevertheless, looking ahead to long-term scenarios simulating multiple days 
at sea, it is a worthy feature and was included in the implementation. 

Wind-generated waves have an important role when attempting to simulate the physical nature 
of the ocean environment. They are the most complex of the environmental disturbances adding 
significant computational complexity to ocean simulation. Despite this complexity their workings are 
well known. Over 40 years of study have lead to the ability to accurately simulate this phenomenon in 
a real-time virtual environment. 

Environmental disturbances are major factors to consider when simulating the ocean 
environment. They are an ever-present force which all sea going vessels must deal with, whether 
surfaced or submerged. Wind, ocean currents and wind-generated waves are significant factors which 


must be accurately simulated to guarantee the success of any vehicle developed for operation at sea. 


E. COMPLEX FLOW-FIELD SIMULATION 


Another field which must be addressed in terms of creating a physically based underwater 
simulation environment is fluid mechanics. Fluid mechanics is an area of study concerned with 
observing fluid behaviors in order to utilize and control the effects of fluid movement for the benefit 
of society (James, Haberman, 1988). There are many laws describing the behavior of fluids in motion 
and various methods of applying them. These laws provide the insight needed to successfully model 
important aspects of the ocean environment. 

The forces generated by fluid movement are of particular concern for the problem at hand: 
torpedo tube docking of an AUV. When a body moves through a liquid it displaces an amount equal 
to its volume. This displaced volume of fluid generates forces as it moves and in turn can apply 
substantial force to other bodies in the area. These forces become significant when considering 
torpedo tube docking for several reasons. 

Torpedo tube docking is a high-risk evolution. There are many things which must be evaluated 
before this type of exercise can be conducted. A primary area of concern is of safety, for personnel 


and for both vehicles. A mistake or accident can place the submarine and her crew in great danger. 
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Depending on the nature of the accident, damage can range from compromising the submarines 
water-tight integrity, to creating a noise hazard making the submarine easily detectable by adversaries, 
to crippling the submarine by damaging the propeller or towed sonar array. 

In order to avoid the above-mentioned problems, it is of paramount importance that the 
development of AUV technology be thoroughly tested. To that end it is necessary to ensure that this 
type of flow simulation can be done in real time. Real-time feedback provides useful insight into 
vehicle behavior in such a complex environment. It gives both designers and users a chance to view 
vehicle behavior and actively discuss improvements. The simulation-based design (SBD) 
methodology is a major factor in assuring that finished products meet user requirements. For that 
reason, it is essential for robot development. 

Another aspect to the importance of body-induced flow has to do with the relative size of the 
AUV versus that of a submarine. Figure 4.4 shows the difference in size between the two vehicles. 
The overall submerged displacement of a 688-class submarine is 6900 tons, with a length of 360 ft 
and a 30 ft beam. When this is compared to the AUV, which in the case of Phoenix is 435 lbs 
displacement, 7 ft length and 1.5 ft beam, it becomes obvious that the force of the water displaced as a 
submarine moves in the area of the AUV must be evaluated and accounted for. 

Flow instabilities are also present along the hull of the submarine. These instabilities, although 
small when compared to the amount of flow generated by the moving submarine, can be enough to 
cause major AUV control problems. Large variations in the force and magnitude of movement 
surrounding the vehicle must be planned for during AUV testing and development. By accurately 
simulating these variations control algorithms can be tested to ensure vehicle stability in even the 
worst-case flow situation. 

The reasons why this type of physically based simulation is needed are plentiful. The 
questions to address now include the methodology used in creating such a simulation and any 
assumptions made to ensure real-time performance. 

Intuition tells that since these local forces exist, they must be applied to every vehicle they 
affect. In other words, the submarine creates a significant field which must be felt by the AUV and 
any other vehicles around, while the AUV simultaneously generates its own field which affects the 


submarine. Herein lies the first simplification. Looking again at the size difference between the 
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submarine and AUV in Figure 4.4 makes it obvious that the displacement force created by the AUV is 
not significant from the submarines perspective. In fact, it can be ignored completely. Since water 
displacement is entirely dependent on the size and shape of the vehicle doing the displacement, it 1s 
necessary to determine the induced flow on a vehicle-by-vehicle basis, taking into account all the 
details of the hull in question. This quickly becomes too computationally expensive for a real-time 
simulation system. Nevertheless, limiting the calculations to one side of the interaction reduces the 


problem by one half, a significant improvement. 





Figure 4.4. Phoenix AUV size (center of image) versus 688 class submarine. 


Inside the virtual environment an area of influence which surrounds the submarine was created 


to represent the flow field. This volume encapsulates all the possible positions that the AUV can be in 
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which are affected by the presence of the submarine. Figures 4.5 and 4.6 give a visual representation 
of this field, with Figure 4.5 showing the side view. It demonstrates that the field exists from bow to 
stern of the submarine. This size field allows modeling the approach of the AUV from any position 


along the hull of the submarine. 





Figure 4.5. Side view of 688 class submarine surrounded by its field of influence. 


While forces do exist forward and aft of the submarine, they are not of concern when 
considering a torpedo tube docking solution, since it is assumed that for the docking evolution the 
AUV will always approach from aft of the torpedo tube door, and it. will not take a path which is 
crosses any of the turbulent flow created behind the submarines propeller. These are reasonably valid 
assumptions. An approach from aft of the torpedo tube door is a necessary fact. This is because the 
submarine must always maintain forward headway to ensure adequate depth and heading control. If 
the AUV were to make an attempt at docking from forward of the submarine, the relative speed 
would be too large to ensure safety and proper control for the evolution. Therefore, the orientation of 
the torpedo tube door must allow rear entry. Figure 4.7 shows a proposed outer door configuration for 
AUV recovery. This provides a unique advantage when conducting the recovery evolution. Adjusting 
the door to move outward has an advantage of being a relatively simple modification to the current 
outer torpedo-tube door configuration, and also provides a sheltered lee for the AUV to move into. 
This lee creates a volume of water for the AUV to perform difficult portions of the docking maneuver 


while sheltered from most open-water flow. 
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Figure 4.6. Front view of 688 class submarine surrounded by its field of influence. 


An approach from the area directly astern of the submarine is not a feasible alternative. The 
reason behind this is inherent in the AUV mission. One of the primary missions for an AUV is mine 
detection and avoidance. The circumstances under which this type of mission is conducted are 
normally those associated with a higher degree of military readiness due to the presence of a possible 
threat. Standard operating procedure for a submarine in that type of environment requires deployment 
of a towed array for enhanced enemy detection and acoustical monitoring. With such a tactically 
valuable (and expensive) piece of equipment trailing from the stern of the submarine, this path 
becomes unavailable for AUV recovery. Thus the AUV is expected to choose an approach from 
behind that is along one side of the submarine, vice fully astern. 

With that in mind, Figure 4.6 gives a better view of the relative area enclosed inside this flow 
field. The cylindrical area extends a distance of 30 ft from the side of the hull giving the area a total 
diameter of 90 ft. Outside this arbitrary volume submarine-induced flow forces are assumed to be 


negligible. 
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Figure 4.7. AUV docking with outward opening torpedo tube door. 


Having examined the size and orientation of the computational model for the flow field, it is 
now necessary to examine what makes up this virtual flow field. The field is comprised of vectors at 
1⁄2 ft intervals. Each one is contains a flow component in the X, Y, and Z direction. The vector 
represents the total amount of flow force (in knots) felt by the vehicle hull at that location relative to 
the submarine. Graphically, one planar slice of the flow-field velocity looks like Figure 4.8. 

This type of grid extends to cover the entire volume within the cylindrical area of influence 
surrounding the submarine. The orientation is such that the innermost row of flow vectors is flush 
with the hull and the outermost follows a line 30 ft out from the hull. An exact flow vector within the 


grid is easily found through position comparison between the AUV and submarine. 
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Figure 4.8. Grid Level inside submarine flow field. 


The construction of the flow field provides some distinct advantages in terms of 
hydrodynamic modeling. In section B of this chapter the high-resolution buoyancy model was 
presented dividing the AUV body into 15 slices. With an AUV length of 7.8 ft this breakdown 
corresponds rather nicely to 2 ft per slice. Thus there is a direct correspondence between the size of 
the grid and the distance between the center of each section along the AUV body. This allows for 
rapid flow vector cross-referencing and application during the cross-body drag calculations. There is 
no need to interpolate between grid positions when retrieving flow vectors for each subsection of the 
vehicle. In fact, the vehicle can move through the flow field at any random orientation and an exact 
position is rapidly determined for the flow force component seen by each section. 

The flow field design eases computational complexity in another area as well. After the 
vehicle position is determined and the flow force vector retrieved it must be applied to the vehicle 
through the equations of motion (EOM). However, by tying the flow field vectors to the submarine 
(global) coordinate system these forces are not in the AUV (local) coordinate system. In order to use 
them in the EOM we must translate them into the local system. Looking at the flow field from the 
AUV point of view, with the submarine on a course of North, it can be said that no matter where the 
vehicle moves in the world coordinate system these velocities will be present. Flow field 
contributions are essentially analogous to the world velocities X-dot, Y-dot, Z-dot, where X-dot 
represents the linear velocity along the North-South axis, Y-dot is the linear velocity along the East- 


West axis, and Z-dot is the linear velocity along the depth axis. This gives a direct relationship 
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between the flow vector velocities and those which can be used in the vehicle's hydrodynamic 
modeling. The velocities can be rotated from the world coordinate system to the local frame of 


reference as follows: 


H X -dot 
v |=| Y-dot | R (4.6) 
νν Z — dot 


where u is surge, vis sway, :w is heave, and R is the (already calculated) rotation matrix. At this 
point we finally have quantities that can be factored into the calculation of the vehicle's cross-body 
drag and incorporated into the EOM. 

Up to this point, a distinct methodology has been presented for deriving flow forces and 
applying them to the vehicle being affected. The next step is to elaborate on the actual data that is 
used to model these complex flow interactions. While looking at this problem several objectives 
come to mind. Typical computational fluid dynamics (CFD) techniques are far too computationally 
complex for a real-time system, so flow data must be precalculated whenever possible to support the 
simulation. 

Extensibility is at the core of this approach to flow modeling. By importing flow data at run- 
time, the virtual environment can be used as a test bed for numerous flow regimes and control 
environments. The simulation is no longer bound to the specific case for which it was developed (i.e. 
tube entry). The data used can represent any type of flow desired. Additionally as advances in the field 
are made, data files can be upgraded to provide a more accurate representation of the fluid's physical 
behavior. The only requirement is that the data files maintain a readable format, and that requirement 
too can easily be manipulated. 

To create the data needed, a generation program was developed based on Fortran source code 
from (Schetz, 1965). The original program generated a flow profile at a single point along a flat plate 
using a two-dimensional (2D) approach to boundary layer incompressible turbulent flow. In order to 
meet the needs of this simulation the code was converted to C++ and modified to include the flow 


models required. The program also generates output data files which are imported into the virtual 
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environment when a docking simulation is initiated. The code for this program is included in 
Appendix D. 

There are two models which are used to create the flow profile down the length of the 
submarine: one for areas of low turbulence, and one for areas of high turbulence. The majority of the 
submarine hull is included in the areas of low turbulence; for these sections a flat plate fluid flow 


model is used. The turbulent portions use a tube-level flow model. 


]. Flat-Plate Fluid-Flow Theory 

The total drag on a body is due to the sum of two types of drag: pressure drag and skin friction 
drag. In many cases one of the two types of drag is dominant (John, Haberman, 1988). In the case of a 
submarine moving through the water, pressure drag dominates. 

One flow model which has many similarities to the application in which this data is going to 
be used is the flat-plate fluid-flow model. It is used to model uniform flow over a flat plate aligned 
with the direction of the flow. Since the flow in question is created by the submarine moving in a 
specific direction through the water, it will always be the case that flow is aligned with the flat plate 
(i.e. submarine hull). 

Additionally flat plate theory assumes that over 90% of the drag caused by flow is pressure 
drag, with only a small fraction due to skin friction. Again this is exactly the case for a submarine 
moving through the water. The shape and special hull treatment of a submarine are designed 
specifically to reduce skin friction and reduce undesirable side effects: increased noise levels, 
reduced propulsion plant efficiency, etc. It can intuitively be asserted that the majority of drag felt by 
a submarine is pressure drag due to the amount of water it must displace to move through the water. 

One remaining question regarding model suitability is whether or not the submarine appears to 
be a flat plate from the perspective of the AUV. Figure 4.9 shows a picture of the AUV next to the 
upper 1/3 of a 688 class submarine. What it demonstrates is the fact that the side of the submarine 
extends 10 ft above the AUV and 20 ft below, looking very much like the AUV against a wall or flat 


plate. For another perspective, one can look at Figure 4.4 to get a wide angle view. 
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Figure 4.9. Phoenix AUV seen adjacent and parallel to the upper hull of a 688 class 
submarine. 


After viewing the comparison it becomes readily obvious that using flat plate fluid flow 
model to simulate the flow field in the areas of low turbulence along the submarine hull is a good 
approximation. 

The use of this type of model provides excellent simplification of the run-time flow 
calculations. It creates simple flow vectors. In fact, they only have one component vice three. Due to 
thé assumption which said that over 90% of the drag which is present is due to pressure drag, not 
friction drag, two of the three components drop out. The flow force is only present along the axis of 
the plate. This means that of the three flow vector components, X-dot, Y-dot, and Z-dot, only Y-dot is 
a nonzero number. The overall profile extending out from the hull is shown in Figure 4.10. 


What Figure 4.10 shows is how flow changes as one moves out from the hull of the submarine. 
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Initially flow is at 0% of the open water velocity and it rapidly increases to 100% as the distance from 
the hull decreases. This demonstrates that the effects of the submarine’s presence are larger as the 
AUV approaches to the hull. The distance at which flow returns to the open water value is 
approximately 25-28 ft. For that reason the flow field extends 30 ft from the hull, which gives a small 
buffer for insertion of more severe flow profiles. It is also interesting to note that as the distance of the 
vehicle moves from the bow to the stern the percentage of open water flow seen by the vehicle moves 


toward 100% more rapidly. This is an expected phenomenon when using a flat-plate approximation. 
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Figure 4.10. Flat-plate flow profile (generated by flow generation code) versus distance 
from the hull of a 688 submarine, shown at 5 locations along the hull. 


The flat-plate fluid flow model provides an excellent match for areas within the submarines 
field of influence where low turbulence is expected. The assumptions inherent in the theory 


correspond almost directly with the characteristics of the problem being addressed. This approach 
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also provides a nice computational advantage since this profile can be used for the majority of the 
submarine. 

Z: Tube-Level Fluid Flow 

Some areas along the submarines hull cannot be approximated by the flat plate model, since 
they are subject to much more complex flow interactions. For the submarine docking problem at 
hand, the area of concern surrounds the open torpedo tube door, beginning slightly ahead of the door 
and continuing back along the hull until flow is no longer disturbed by the instabilities caused by the 
open door. 

This type of flow profile is similar to those experienced when viewing flow over a cavity. In 
this case the torpedo tube outer door acts as a shield and the tube area is the cavity. The behavior of 
flow in this type of situation is very complex and poorly defined. There is a great deal of active 
research being done on flow fields since many aspects of flow behavior are poorly understood. What 
is known gives enough of a picture of the flow interaction to make this simulation as accurate as 
possible. 

To accurately model this type of flow there are three portions to take into account: the flow 
approaching the tube, the flow inside the cavity (and directly aft of the tube) and the rest of the flow 
path from aft of the tube to the stern. 

The flow area forward of the tube is easily modeled. As flow moves along the hull the 
protruding torpedo tube door forces an outward movement of the flow. In this area each flow vector 
now has a magnitude in the x direction, out from the hull, and the y direction, along the hull. Figure 


4.11 portrays the overall flow picture in this area. 
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Figure 4.11. Flow interaction as it approaches an open torpedo tube door. 


Figure 4.11 depicts how the flow moving along the hull is forced outwards creating a flow 
force vector which moves away from the hull and aft. After the end of the door is reached the flow 
interaction becomes very complex. In this area a dead zone is created inside the cavity. In the cavity 
area there are no significant flow forces at all. As displaced water moves back into the area behind the 
torpedo tube, a time-varying flow-profile is created. Vortices are created at varying frequencies along 
the path that follows the door. Figure 4.12 gives a top-down view of what the flow profile resembles 
at a given moment. The dead zone represented by the shaded area moves along with the submarine as 
the vortices are created directly aft of the area. Some small flow aft may exist in this dead zone if 


water 15 permitted to pass through openings where the door meets the hull. Such small flow may also 


help stabilize turbulence. 
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Figure 4.12. Flow movement aft of the torpedo tube door. 


The final area to examine is aft of the tube disturbances. In this area flow has stabilized. АП 
the complex interactions caused previously have subsided. Here it is again possible to model the flow 
field as a flat plate. The only additional disturbances present in this area are those created by pump 
suctions and discharges. 

The flow interactions present on the tube level of the submarine are quite complex. This 
influence is time varying and not yet fully understood. The majority of the interactions take place on a 
small scale (less than inches) that a scale of % foot intervals between flow measurements can only 
approximate. In this simulation the variance of flow in this situation has been captured at a low level 
of detail. As advances are made in the understanding of fluid flow over cavities it will be possible to 


upgrade the resolution of flow vector data used. For the time being this model provides a plausibly 


-52- 


accurate testing environment for AUV interaction within complex flow situations. By examining 


approximate but worst-case conditions, an estimate of the magnitude of flow effects can be simulated. 


F. EQUATIONS OF MOTION (EOM) 


The Phoenix AUV virtual environment uses a Newton-Euler approach to the six degree of 
freedom (DOF) EOM. This accurately models the kinematics and dynamics of a rigid body vehicle 
moving without constraint (Brutzman, 1994)(Healey, 1998). These equations have been partially 
verified through extensive testing in the virtual environment coupled with in-water mission analysis. 
In all cases the results experienced in the virtual environment demonstrated proper behavior, as 
evidenced by similar results during in-water runs of identical missions. Additional testing 1s needed to 
quantify the effects of recent hardware improvements (such as larger shrouded propellers). 

In order to properly integrate the flow forces previously discussed into the virtual 
environment, we examine the EOM looking for the proper terms to modify. Equation 4.7 is the sway 
equation of motion from (Brutzman, 1994) which is implemented in the Phoenix AUV virtual 


environment. 


Sway Equation of Motion (4.7) 
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The variables and coefficients in the sway equation of motion are defined in (Brutzman, 1994). 

The terms of the EOM define all the major force contributors to vehicle motion. Similar 
equations exist which define surge, heave, roll, pitch, and yaw. These can be found in (Brutzman, 
1994). For this discussion, the sway equation of motion is used as an example. 

For the problem at hand it is necessary to integrate the additional flow force contributions into 
the EOM. Since the body-induced flow forces are primarily due to the cross-body drag of the water as 
it passes over the vehicle, the logical place to insert these factors is the term dealing with cross-body 
drag. To do so we must first examine precisely how these velocities induce drag. 

5 Round Hull Derivation 

Cross-body drag is calculated to incorporate the force generated by the motion of water over a 
rigid body. When determining the magnitude and direction of this force one must know the shape and 
size of the body being effected. In past versions of the EOM it has been assumed that the shape of the 
body was always cylindrical. This provides a solution to the six degree of freedom model that is 


general enough to accurately depict the cross-body drag for the majority of submerged vehicles. 


Incident Force 


esultant Force 


Resultant Force = Incident Force 





Figure 4.13. Flow force incident upon a round body. 


For a round body the force applied by the water is always in the same direction as the original 
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force. When calculating the cross-body drag the v and w components can be found by the breaking the 
force up into the respective components, Fy and Fw, then normalizing. Figure 4.13 gives a visual 
representation of these forces and their components. 


The terms can be defined mathematically as follows (Healey, 1998): 


l l 
F = 5 C ppv dx F, = ; Copw da (4.8) and (4.9) 
Going one step further it can be said that 
у= у, + хг (4.10) 
апа 
W = W, + xXq (4.11) 


Taking these facts and adding a term for normalization gives the final version of the cross-body drag 


formulation. 
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These forces are incorporated into the EOM as one of the multiple terms present. Translating 


the forces into the rigid body's reference frame and integrating their effect along the horizontal axis of 
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the body results in the fifth term on the right hand side in the sway equation of motion. 

This term represents the effects of flow forces across the spherical rigid body. As is evidenced 
by the derivation of the forces, shape of the rigid body does make a difference. In the case of the 
Phoenix AUV, which has a rectangular shape, this generic model 1s inaccurate. 

2; Square Hull Derivation 

When a flow force is incident upon a rigid body that does not have a spherical shape the 
direction of the resultant force is not necessarily the same direction the force came from. Figure 4.14 
demonstrates this fact. Given a force incident upon a rigid body with a shape that 1s rectangular, the 
resultant force is not equal in magnitude or direction to the resultant force. 

The initial formulation from the round hull derivation of cross-body drag is similar, but the 
terms cannot be normalized using Ucf. The reason for this is that Ucf is radialized and it is no longer 
the case that the forces are radially symmetric. This causes some differences to exist between the 
cross-body drag term in the EOM for a spherically shaped body versus the same term in the EOM for 
a non spherical body. The formulation for Fy and Fw in this case are given in (4.14) and (4.15) 
(Healey, 1998). 


Incident Force 


Resultant Force 


Resultant Force » Incident Force 





Figure 4.14. Flow force incident upon a non-spherical 
rigid body. 
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(4.14) 


l > 
" = 5 CoP σα 
(4.15) 
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Taking these revised force formulations and incorporating them into the EOM to make a more 
specific set of equations yields the sway equation of motion given in (4.16). This equation provides an 
accurate evaluation of cross-body drag and 1s computationally less complex than the spherical hull 
case. Thus it provides two advantages. Similar specializations are performed for the equations of 


motion for heave, pitch, and yaw. 


Square Hull Sway Equation of Motion (4.16) 
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In order to improve the accuracy of the Phoenix AUV virtual environment without limiting its 
extensibility, both models are incorporated in the implementation. The user can select the shape of the 
hull being tested in the virtual environment, and based on that selection the appropriate version of the 


EOM will be used. 


G. SUMMARY 


The environment plays a major role in all aspects of AUV research and design. If a virtual 
environment is to act as a true test bed for newly engineered, devices it must take into account the 
forces of nature. The virtual environment used for testing and development of the Phoenix AUV 
incorporates many environmental factors into its simulation. The virtual environment is truly 
physically based. The enhancements added throughout this work incorporate a highly detailed 
buoyancy model, wave motion simulation based on the Pierson-Moskowitz wave spectrum, a detailed 
methodology for simulating body induced flow forces, and a specialization of the equations of motion 
to offer a higher resolution method for modeling cross-body drag on non spherical rigid bodies. 

All of these factors serve to enhance the realistic behaviors which are present inside the 
Phoenix AUV's virtual environment. Improvements of this type can only better performance leading 


to 1mproved design, testing, and final product. 
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V. IMPLEMENTATION 


A. INTRODUCTION 


As with any technically based research, there needs to be some proof of correctness for the 
various theories presented. This chapter examines two separate implementations of the Phoenix 
AUVs virtual environment. The initial implementation was done using C++ and Silicon Graphics 
OpenInventor Application Programmers Interface (API). This version runs solely on Silicon Graphics 
workstations. A second platform-independent, implementation was created to run on any machine 
upon which the Java runtime environment is present. Each version uses the DIS protocol for 


networking enabling the user to run a mix of viewer and dynamics versions if desired. 


B. C++AND OPEN INVENTOR 


The virtual environment is primarily comprised of three components. In their original 
implementation the dynamics program was written in C++, robot execution level in C, and the viewer 
in C++ using the OpenInventor API (Brutzman, 1993). Each component was thoroughly tested and 
the performance was validated by real-world experiments. With this history in mind, the logical 
choice is to first implement the flow and buoyancy models in C++ before the transition to Java. 

The wave model and the submarine-induced flow forces both relate to the environments 
effect on the AUV, thus both are implemented in the dynamics code. The code itself is located in a 
function called calculate_equations_of_motion() which is included in Appendix A. 

The algorithm for the wave model uses the P-M spectrum as discussed in Chapter IV. For each 
time step, the height of the wave is calculated for the fifteen sections down the AUV body length. At 
each block, a force vector proportional to the wave height is assigned. After stepping down the length 
of the body the vectors are added and averaged to get an overall force that acts upon the entire AUV. 
This superposition vector is used to adjust the center of buoyancy of the vehicle prior to completing 
the integration of the equations of motion. The overall effect is a pitching moment that is proportional 
to the wave position over the body of the vehicle. Figure 5.1 presents the pseudocode for the wave 


algorithm. 
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for ( 1 to number of sections)  ( 
Calculate wave motion buoyancy for this block 
if (depth > 20 ft) { 
Reduce wave buoyancy effect due to depth 
j 
Determine overall direction of wave motion 


) /lend of for loop 


for ( 1 to number of sections) { 
Adjust vehicle buoyancy based on wave motion 


Adjust center of buoyancy based on direction of wave motion and pitch angle 


} 


high-resolution buoyancy force calculation complete 





Figure 5.1. Pseudocode for wave motion effect algorithm. 


The next algorithm incorporated into the equations of motion provides the forces created by 
the submarine's flow field. As described in Chapter IV the flow field exists in the area of water 
surrounding the submarine. The implementation of this algorithm is more complex than that of the 
wave model. It requires several calculations for each section of the AUV body. Each one providing 
information for the next iteration down the body. Figure 5.2 contains pseudocode of the general 
algorithm. 

The first step is to determine whether or not the AUV is inside the influence field of the 
submarine. This is done by comparing the position of the AUV to the position of center of the 
submarine. Having knowledge of the volume of water which falls into the flow field allows for quick 


determination of whether or not submarine flow interactions must be calculated. 
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Compare the position of the AUV to that of the submarine 
if (inside flowfield) { 
Set flowfield flag to TRUE; 
| 
for ( 1 to number of sections ) { 
Calculate the x-position of the current section 
Calculate the y-position of the current section 
Calculate the z-position of the current section 
Determine the position of the AUV relative to the submarine center 


Index into flow field matrix and retrieve the flow force at that point, without interpolation 


Calculate a rotation matrix to translate x,y,z force components into body coordinates 


for (1 to number of sections) { 


Translate current section forces into body coordinates 


//Cross Body Drag Contribution 
Calculate flow. field sway. integral 
Calculate flow. field surge. integral 
Calculate flow field, heave. integral 
Calculate flow. field roll integral 
Calculate flow. field. pitch, integral 
Calculate flow. field. yaw, integral 
| 
Add flow field integrals to cross-body drag integrals 


Figure 5.2. Pseudocode for flow field algorithm. 
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Once it is determined that the AUV is inside the flow field, more detailed calculations are 
performed. These include finding the position of each section's center and the position of that section 
inside the flow field. Figure 5.3 demonstrates the geometry of calculating the x position of a section. 
Knowing the heading of the AUV and the orientation of the world axis, each coordinate position can 
be determined using simple geometry. A similar method is used for determining the y and z values 


for a section of the hull. 


Distance 
from AUV 


Center 





Difference 


AUN x Section X X-Axis 
Position 


X = AUV x * sin (90-Heading Difference) 
* distance from AUV Center 


Figure 5.3. Geometry of calculating an AUV sections X position 
relative to the center of the AUV. 





Once the x, y, and z coordinates of a body section have been determined, they are used to 
calculate the position inside the flow field. This process takes two steps. First, the relative position of 
the AUV to the submarine is determined, then the relative coordinates are converted into flow-field 
indices. 

The X component represents the AUV position along the hull of the submarine with a value of 
zero ft meaning at the bow and 360 ft at the stern. The X value corresponds to the distance from the 


bow of the submarine in feet. This is determined by simply taking the difference between the X 


ο». 


position of the submarine and the X position of the AUV. 

The next relative position component is the radial distance of the AUV from the centerline of 
the submarine. It combines both the y and z positional components into a single number (Equation 
5.1). This is used because the construction of the flow field is such that the grid 1s anchored at the 
center of the submarine. To get at any particular position out from the hull the overall radial distance 


is needed as an index. 
2 2 
RadialDist — (Ydifference) + (Zdifference) S 


The conversion step takes the X-position with the radial distance and then converts the pair to 
flow field indices. The numbers cannot be taken directly because the grid has a resolution of % ft 
increments. This causes the grid positions to range from zero to 720 along the hull and zero to sixty 
out from the hull. The conversion simply takes the calculated coordinate and makes it into an integer 
position which can be used in the flow field system. 

Having the proper indices available it is now possible to retrieve the values of flow forces seen 
by the section of the AUV being considered. The flow induced forces are stored velocities in the 
world coordinate system. To apply them to the equations of motion in the local coordinate frame they 
are translated into body coordinates using equation (4.6). No interpolation is performed due to already 
high resolution, reducing computational complexity. The forces are then applied to the EOM by 
adding their effects into the calculation of cross-body drag. 

The algorithms for wave motion and body-induced flow forces are tightly interlaced in the 
dynamics code. Many of the calculations required for the wave model are also needed for the flow 
field and vice versa. By conducting the computations in tandem the added execution time is kept to a 
minimum. It enables an already computationally complex virtual environment the ability to become 
more accurate, yet still run in real-time. 

Other changes to the virtual environment involved additions to the viewer program. The 
viewer provides a window into the virtual environment. For the experiments conducted in this thesis 
It 1s necessary to visualize the AUVs approach and rendezvous with a submarine. In its initial 


incarnation the virtual environment did not contain a submarine. It was primarily used to develop 
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robot control algorithms for open water situations. It also provided a replica of the NPS test tank for 
small-area testing which might later be conducted in the actual tank. As the focus was moved away 
from small-area operations to open-water docking, a 688 class submarine model was added to the 
environment. The addition turned out to be an invaluable visualization tool and presented an added 
feeling of AUV scale in the open ocean. 

Implementing the wave buoyancy model and the body-induced flow algorithm in C++ 
provided an excellent stepping stone in the development process. Knowing the original version of the 
virtual environment was validated and sound allowed for quick isolation of possible modeling errors. 
Any instabilities encountered were localized to either of the new algorithms. It also provided the 
groundwork for the later implementation of dynamics in Java. In summary: development and 


implementation of the high-resolution models was successful. 


C. JAVA AND VIRTUAL REALITY MODELING LANGUAGE (VRML) 


After proving the validity of the models proposed by this thesis, the next step was to provide a 
platform-independent version of the code. This was not possible using C++ and the OpenInventor 
API. C++ is plagued by compiler differences from one platform to another, and the OpenInventor API 
is primarily for Silicon Graphics workstations, although a port of the library to Windows95 has 
recently been completed. In any case the only way to provide true platform independence was to use 
languages which were not platform specific. For that reason Java in combination with VRML are the 
language of choice. 

The first portion of the virtual environment converted was the dynamics program and 
associated functions. This was a relatively straightforward port of C++ to Java. While some problems 
were encountered due to differences in language functionality (i.e. object handling, operator 
overloading, pointers, etc.) it was more time consuming than complex. Appendix B contains a list 
description of the code for the virtual environment dynamics in Java. The functionality and object 
hierarchy of the dynamics program is the same in the Java and C++ version, as is most program 
syntax. Flow field matrices proved too large for current PC java implementation, so this section of. ` 
code is commented out. 


The second step in the move towards platform independence was to re-implement a viewer 
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program in a platform-neutral way. VRML was used to describe the virtual environment scene graph 
with Java as the language to animate the objects in the environment. This gives anyone with an 
Internet browser (and appropriate VRML plug-in) the ability to view the virtual environment. 

The difficulties in porting the viewer to a platform independent scheme were primarily due to 
problems with Internet browsers and VRML plugins. Due to the early development stage of both of 
these technologies, many inconsistencies were encountered. These implementation problems were 
handled by the DIS-Java- VRML working group. Numerous work-arounds and problem solutions 
were developed in the working group forum. They provided the Java implementation of the DIS 
protocol and the bridge from multicast broadcast to unicast so the VRML scene can be animated via 
the script node. Figure 5.4 shows the underlying architecture of the Java-VRML version of the 
Phoenix АСУ virtual environment. The source code for the VRML scene is available via references 


in Appendix B. The source for the DIS-Java-VRML library is available at 


[http: www. stl.nps.navy.mil/dis-java-vrml]. 


DIS 


Network 


Figure 5.4. Platform-independent architecture for Phoenix AUV virtual environment. 





The transition from a platform specific virtual environment to a platform-independent one is a 
large step forward in simulation technology. As personal computers become better and platform- 


independent languages more robust, this transition can only get easier. 
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D. SUMMARY 


This chapter describes two separate implementations of the Phoenix AUV virtual 
environment. The C++/OpenInventor version is an extension of the original virtual environment, 
providing the speed and additional functionality needed to perform the SBD of torpedo tube recovery, 
while still using a validated base environment for quick isolation of problems. The DIS-Java-VRML 
implementation gives the virtual environment portability. It is now possible to view simulations from 


any machine having Internet connectivity. 
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VI. EXECUTION LEVEL AND VIRTUAL DOPPLER SONAR 


A. INTRODUCTION 


The Phoenix AUV execution level software controls all the hardware onboard the vehicle, 
ensuring all hard real-time deadlines are met. It uses a sense-decide-act loop to iterate through the 
process of polling sensor and effector state, deciding what actions are required and then commanding 
devices to the proper state. The devices that are controlled range from motors and servos to gyros and 
sonars. This chapter discusses a new sensor, a doppler sonar unit, which is simulated in the virtual 


environment and used for advanced control law testing. 


B. TRITECH DS30 PRECISION DOPPLER SONAR 


Doppler sonar works on the basic theory of measuring the frequency shift in a transmitted 
signal. The TRITECH DS30 precision doppler sonar is a highly accurate, reliable, compact unit 
designed for underwater vehicle use. It provides measurements of vehicle speed by analyzing the 
frequency shift in the back-scattered signal (MECCO, 1997). The DS30 is comprised of three major 
components: a digital micro controller, an analog control circuit, and a transducer. 

The digital micro controller controls the transmitter, the receiver, a Programmable Logic 
Device (PLD), and manages data communications to an external control device. Data output provides 
a bottom speed vector, water mass speed vector, and the current depth. Both vectors can be presented 
in either polar or rectangular format. The speed vectors are given in meters per second, with an 
accuracy of one centimeter per second and depth indication is accurate to one centimeter. 
Communication with the sonar is conducted through a 9600 baud serial line. This line handles both 


data output and command input. Figure 6.1 gives the specification data for the DS30. 


i692 


Power consumption 
Operating frequency 
Operating range for seabed tracking 2-30 meters 


Tracking modes Velocity relative to seabed & velocity relative to seawater 


Data rate Up to 5 updates per second 


RS232 as standard, RS485 as option 

Operating velocity O-3.75 meters/second 
Velocity accuracy............. D CQ TL QS 2.5 centimeters/second 

Velocity resolution........... a UD TUIS 0.5 centimeters/second 
Transducer 4 beam Janus array 

Configuration Convex, beams @ 45° to vertical 
Source level 217 dB re. 1 uPa @ ] meter 
1000 meters 

360 millimeters including connector 

120 millimeters 

130 millimeters 


М/с ШИ Г едК ο ο ο ο ο ου... 5.5 kilograms 





Weight in water 2 kilograms 
Figure 6.1. Tritech DS30 precision doppler sonar specification from (MECCO, 1997). 


The DS30 analog control circuit is comprised of one receiving channel and one transmitting 
channel. It achieves a four-channel system by multiplexing the receiver/transmitter circuits to each 
transducer element. The transducer is constructed with four elements, each at 45° offset from the 


normal axis (MECCO, 1997). Figure 6.2 is a picture of the DS30 mounted on the front of the Phoenix 
AUV. 
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Figure 6.2. Tritech DS30 precision doppler sonar mounted on the 
nose of the Phoenix AUV. 


The Tritech DS30 precision doppler sonar is a unit which is well suited to the Phoenix AUVs 
needs. It is an accurate sensor which can be easily integrated into the vehicle due to its low cost, low 
power requirements, and standard communication setup. The DS30 provides all the needed 


components to accurately measure cross-body flow and use that information for enhanced modes of 


AUV control. 
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C. SONTEK ACOUSTIC DOPPLER VELOCIMETER (ADV) 


The Sontek acoustic doppler velocimeter (ADV) is another device which can be used to 
determine cross-body flow for the Phoenix AUV. It is an acoustic doppler current profiler and has the 
ability to determine water velocity in three component axis. The Sontek ADV works by measuring the 
velocity of a volume of fluid that is directly above its probe and has an accuracy of 0.1 
millimeters/second. This type of technology is designed to accurately measure ocean current, and it is 
well suited to be used as a cross-body flow sensor on the Phoenix AUV. The specifications for this 
device are given in Figure 6.3. Eventually in-water testing will also examine whether the velocity 


update rate is sufficient fast for real-time maneuvering control. 


Power consumption 


Operating frequency 


Data rate............. κ ОИ. . 0.1 to 25 Hz 
Communication 
Operating velocity. siete ИИИ 2.5 meters/second 
Velocity resolutio. eseese t ............... IK m M 0.1 millimeters/second 
30 meters 
407.9 millimeters including connector 


76.2 millimeters 





Figure 6.3. SonTek acoustic doppler velocimeter (ADV) specification from (SonTek, 1997). 
The Sontek ADV is a new device which is specifically designed for shallow water operations.. 


Figure 6.4 is a picture of the SonTek ADV. This unit is currently being evaluated for use in the next 


incarnation of the Phoenix AUV. 
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Figure 6.4. Sontek acoustic doppler velocimeter (ADV ). 


e 


D. VIRTUAL SIMULATION OF DOPPLER SONAR 


Before a new sensor is integrated into the Phoenix AUV and deployed for in-water testing, 
SBD practices suggest that its use be simulated and evaluated first. To this end a virtual sensor was 
implemented to represent the Tritech DS30 precision doppler sonar. It was created to provide the 
same functionality in the virtual world as is expected from its performance in the open ocean 
environment. The simulation was developed in several steps to ensure accuracy of each portion of the 
model. 

First, the doppler sonar was integrated into the execution level code in function 
closed loop. control, module(). In the sense phase of the execution level's sense-decide-act loop, 
variables were added to read the sensor input. Since the true hardware is not present in the simulation 
this was accomplished by adding the needed parameters to the state vector. The state vector represents 
the value (or state) of every sensor and effector in the vehicle. This is the information that is sent to 
the dynamics model to provoke the appropriate forces, or measure the needed quantities, in the 
surrounding virtual environment. 

The next step included the addition of a sensor model to the hydrodynamics code. This was 
necessary so the dynamics model might return proper values to the execution level, when the 
execution level indicated use of the doppler sonar via the state vector. For this thesis a simple zero- 
order model was constructed. The value returned by dynamics is the true error-free value of the 
| quantity being measured. In other words, there is no error due to random noise or uncertainty inserted 
in the response. The assumption for beginning testing and evaluation is that the sensor will work 
exactly as described by the technical documentation on the sensor. Granted this is not always a valid 
assumption, nonetheless it is sufficient for initial testing. Random noise and errors can easily be 
incorporated at a later time, since it is more appropriate to examine performance failure modes after 
the sensor had been proven useful in the optimal case. 

The final step for sensor integration is to provide a facility to exercise all the control and data 
modes of the DS30. To accomplish this step, commands must be added to the execution level 
command language. The device itself has a series of roughly ten commands, ranging from reset to 
designating sampling frequency. During initial device testing it is only necessary to accurately parse 


the output data. The data provided by the unit in its normal mode contains both the unit's speed over 
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ground and the speed of the water column. These values are all that is needed for the cross-body flow 
calculation input to the vehicle control laws. Thus, implementation of a full command language for 
the unit was deferred as future work. 

The simulation of the Tritech DS30 precision sonar 15 a useful tool for testing and 
development of robot control modes. By separating the process into well defined components 
researchers are able to keep robot-specific code in one module and hydrodynamic code in another. 
The processes communicate via a state vector which is read by the robot execution level as if it were 
getting the data directly from the actual sensor. This makes the transition from the simulation 


environment to the real world transparent from the robot’s point of view. 


E. ENHANCED CONTROL LAWS 


The addition of any useful sensor is an iterative process. In order to improve vehicle control 
the sensor must be evaluated, prototyped, and integrated into the existing system. The Phoenix AUV 
control laws are no exception. These laws are finely tuned to provide a properly damped control 
system. The addition of a doppler sonar which can provide cross-body flow information requires the 
adjustment of these laws to incorporate (and take advantage of) the new information available. 

In order to use the information available from the doppler sonar unit, it is necessary to 
evaluate which positioning mechanism can best use this information. The question is primarily 
whether to adjust the control of the rudders, the fore and aft thrusters or both sets of effectors. In the 
case of the rudders, which are primarily used during forward transit, cross-body flow information is 
not significant. Since the employment of this sensor is envisioned to be a mechanism which allows 
the AUV to predict turbulent flow areas before the entire body is pushed unstable by them, rudders 
are not the most effective control devices. Instead the virtual cross-body flow sensor is used for 
adjusting thruster control laws. 

Thrusters can be used to orient the vehicle horizontally and counteract cross-body flow quite 
effectively. As the AUV moves into a turbulent area the sensed cross-body flow can be used to 
activate a thruster force counteracting the instability caused by the turbulence. Thus the thruster 
control laws are adjusted to include a term for cross-body flow data. Figure 6.5 gives the new thruster 


control law. 


ida. 


AUV sSstern lateral 2 (-k thruster psi * normalize2(psi-psi command) 

- k thruster r *r) 

4 k thruster hover * cross track distance 

- k thruster current * AUV oceancurrent x 
* sin psi 

+ К thruster current. * AUV oceancurrent y 
* cOS psi 

-k sway. hover τν 


ΕΚ thruster current * cross body flow u[12]; 


Figure 6.5. New thruster control law for the AUV stern lateral thruster. 


This new control law can be written in two ways: as a straight sensor input or as a smart 
sensor. The straight sensor input takes the value sensed by the doppler sonar and uses it in the forward 
lateral thruster control law since that is the relative location of the physical sensor. A smart sensor is 
one which “dead reckons” the sensed cross-body flow using the vehicles recent movement history and 
can predict the flow at both forward and aft lateral thrusters. In this case both thrusters can be 
effectively employed to counteract the turbulent flow encountered. Both of these control law options 
were implemented and tested. The results are presented in Chapter VII. 

The integration of a new sensor into AUV control is a significant task. Simulation testing 
shows that the doppler sonar sensor provides useful information which needs to be integrated into 
vehicle control. This section presented an alteration to the vehicle control laws for cross-body 
thrusters in addition to two methodologies for sensor employment. These are the first attempts at 


harnessing the wealth of information available from such a useful piece of equipment. 


F. SUMMARY 


The abilities of the Phoenix AUV to see the environment in which it operates are limited by its 


sensor suite. Improving the way the AUV observes the environment and increasing sensory input 


ТАЕ 


provides additional information for vehicle control law action. In order to thoroughly test the use of 
these sensors, they must be integrated into the execution level code and tested in the target 
environment. One such device which appears to greatly improve vehicle control is a precision doppler 
sonar. This chapter demonstrated the simulation of a precision doppler sonar and the integration of its 
output information into enhanced vehicle control laws. The results acquired from simulating such a 
sensor demonstrate how useful the information is to AUV control and the significance of sensor 


simulation in the vehicle design process. 
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VII. SIMULATION RESULTS 


A. INTRODUCTION 


This chapter outlines and presents experiments conducted to validate the simulations 
implemented in this thesis. The experimental design is addressed along with the measures used to 
qualify and quantify results. Then the final results are presented in concise tables which are supported 


by plots provided in Appendix C. 


B. DESIGN OF EXPERIMENTS 


When developing tests to validate the implemented cross-body flow and associated AUV 
control algorithms, it is necessary to examine two areas: the high-resolution buoyancy model with 
wave action effects, and the flow field interaction algorithm. In order to properly test each area 
separate experiments were designed. Each experiment focuses on the concerns associated with the 
particular application being tested. 

For the testing of the high-resolution buoyancy model, a series of simple missions were 
conducted under various sea-state conditions. During these experiments the Phoenix AUV was placed 
on a base course heading into the sea at a speed which was high enough to allow the vehicle to 
maintain heading, while low enough to prevent vehicle control from masking the effects of the sea. 
The mission script used (mission.script.SeaStateTest) is included in Appendix C. 

During these tests it was also necessary to determine specific factors which might be used to 
quantify and qualify the results that were found. In terms of vehicle stability while heading into a sea 
the primary factors of concern are maximum pitch angle and pitch rate. These parameters are 
appropriate because they directly indicate the vehicle’s stability and ability to maintain control as it 
moves through the seas. 

The termination consideration for these tests is determination of what sea state to end the 
analysis. While the hydrodynamics model may be able to produce a sea state ranging from one to 
nine, at some point the vehicle becomes so unstable that its presence is not worthwhile. Thus the 
analysis range from minimal sea states (1) to a sea state in which the vehicles stability was in 


questionable for greater than 50% of the run. 


Ge 


In the first group of experiments, the high-resolution buoyancy model is tested in sea states 
ranging from one to a sea in which the vehicle does not maintain stability. During each exercise the 
AUV proceeded on a course directly into the sea at a speed high enough to maintain steerage. These 
runs fully exercised the high resolution buoyancy model and the wave motion simulation. The 
experiments are designated SS.1 through SS.5 corresponding to sea states one through five. 

The second set of experiments are aimed at testing the flow-field simulation and vehicle 
control using cross-body flow sensor input. The goal is to bracket the torpedo tube docking problem 
by running experiments in flow conditions which ranged from lower than expected turbulence levels 
to well above expected turbulence levels. Additionally, the results with the cross-body sensor 
available are compared to runs with the sensor absent. Table 7.1 shows the naming convention for all 


of the experiment variations. 


LUSSI Z€Š=ƏZ€ESZB=zGƏGH=IIZG No Flow Field Normal Flow Field Extreme Flow Field 
No Flow Sensor Experiment CBF.1 Experiment CBF.2 Experiment CBF.3 


Flow Sensor Experiment CBF.4 Experiment CBF.5 Experiment CBF.6 . 
Smart Control Sensor Experiment CBF.7 Experiment CBF.8 Experiment CBF.9 


Table 7.1. Variation of conditions for experimental cross-body flow (CBF) missions. 





While running the CBF missions, three criteria were chosen to quantify observed results: 
vehicle distance from track, time to regain track in turbulence and whether or not the vehicle collided 
with the submarine hull during the docking mission. These parameters are appropriate because they 
directly address AUV survivability during torpedo tube recovery. If flow perturbations cause 
significant variance from the preplanned track, then AUV endurance and control become a concern. If 
collision occurs, then safety of the AUV and the submarine become significant. Thus these metrics 
provide a useful measure of AUV performance in the presence of turbulent flow. In each run the 
commanded path was identical, as specified by the mission script mission.script.FlowFieldTestLoop 
included in Appendix C. 

The combined results of these experiments provide a sound measure of the algorithms 


developed in this thesis. They address the performance of the high-resolution buoyancy model, the 


-78- 


wave motion simulation, the turbulent flow field simulation, and the cross-body flow sensor control 
algorithm. These simulation experiments also serve to illustrate the accuracy of the physically based 
models they are derived from. Any errors in a cross-coupled model as complex as vehicle dynamics 


will almost certainly cause vehicle instability in the virtual environment. 


C. RESULTS 


The experiments described in the previous section were conducted ising the Phoenix AUV 
execution level and the C++ implementation of the virtual environment. The results were measured in 
terms of the metrics discussed, collected in the form of parameter graphs included in Appendix C and 
summary tables presented in this chapter. 

The experiment which exercised the high-resolution buoyancy model and the wave motion 
simulation provided interesting results. The vehicle was able to maintain stability in sea states ranging 
from zero to five. In sea state five the vehicle was unstable for roughly 60% of the 5 minutes that the 
run lasted. Nevertheless, the control algorithms were able to maintain a relatively stable attitude while 
the vehicle was moved by large wave swells. Vehicle pitch rate and maximum pitch angle varied 
greatly between sea states as expected. Table 7.2 contains the data addressing these metrics. Worth 
noting is the dramatic increase in pitch rate and pitch angle when the sea state progressed from four to 
five. It is likely that shorter sampling rates, modified control coefficients and the predictive control 
algorithm specified in (Riedell, Healey, 1998) can improve performance even further. Surprisingly the 
vehicle was able to maintain control in sea states well above what was expected. Further in- water 


testing is definitely needed to validate these results. 


Experiment 


Pitch rate 
x (deg/sec) 


Maximum 0.35 | ! 40.0 
pitch angle (0.15 avg) (1.5 avg.) (4.5 avg) (11.0 avg.) 
(deg) 
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Approximate 
amount of 


time vehicle 
was unstable 





Table 7.2. Experimental results of AUV stability in various sea states. 


The results from the experiment which tested vehicle control in the flow field are also 
significant. For the most part the results are as expected. The first metric used, collision with the hull, 
gives a boolean result for each run. Table 4.3 contains the data collected for runs under all of the 
various conditions. In the no flow and normal flow conditions, vehicle control was stable enough to 
prevent the AUV from colliding with the submarine hull. In the extreme flow case the AUV collided 
with the hull in every case, regardless of sensor control. The point at which collision occurred was at 
the pump suction inlet along the hull. In the extreme case the suction flow simulates a flow of 1.3 
knots vice 1.0 knot in the normal flow case. This slight increase in flow force creates a significant 
problem for AUV control. Despite flow turbulence near the torpedo tube door, no collisions occured 


in the door area. 









o Sensor 
CBF.1: No Collision CBF.2: No Collision CBF.3: No Collision | 

| 
Normal Flow Profile CBF.4: No Collision CBF.5: No Collision CBF.6: No Collision 


| 
Extreme Flow Profile CBE.7: Collision at CBF.8: Collision at CBF.9: Collision at 
pump suction onl pump suction onl pump suction onl 


Table 7.3. Cross-body flow (CBF) experimental results of AUV collision with submarine hull. 


Simple Control Sensor | Smart Control Sensor 














The other measures evaluated are the overall distance the vehicle departed from its pre- 
planned track due to turbulent flow and how long it took to return to track after departure. Departure 
from track was measured in the most turbulent areas within the flow field: the pump suction, pump 
discharge, and torpedo tube door docking. Table 7.4 presents the results of these measures at the three 
points for each experiment. These results are as expected when moving from one flow condition to 


another. Yet the results within each condition show that the cross-body flow sensor input to thruster 
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control has no significant effect on distance from track, but does aid in the time needed to get back on 
base course. The lower return times are most likely due to the fact that the thrusters are helping to 
stabilize the vehicle when the cross-body flow sensor is used. More accurate testing of the adjusted 
control laws is needed. Nevertheless, the control results are promising. The additional sensor does in 
fact provide some additional thruster control ability. It is left to future researchers to implement a 


more effective control law. 


Flow Condition Position No Sensor Simple Control | Smart Control 
mr z —_ Sensor 
No Flow | Distance from track at 
| | pump discharge (feet) 
No Flow Time to regain track 
(seconds) 
No Flow Distance from track at 
pump suction (feet) 
No Flow Time to regain track 
(seconds) 





No Flow Distance from track at 
torpedo tube entry 
(inches) 


No Flow Time to regain track 
(seconds) 





Normal Flow Distance from track at 13 
Profile pump discharge (feet) 

Normal Flow Time to regain track 55 
Profile (seconds) 

Normal Flow Distance from track at 
Profile pump suction (feet) 

Normal Flow Time to regain track 44 
Profile (seconds) 


DL 


CA de 
+ — 


+ 
© 


Normal Flow Distance from track at 


Profile torpedo tube entry 


(inches) 





-ᾱ]- 


D. 


Normal Flow 
Profile 


Extreme Flow 
Profile 


Extreme Flow 
Profile 


Extreme Flow 
Profile 


Extreme Flow 
Profile 


Extreme Flow 
Profile 


Distance from track at 
pump discharge (feet) 
Time to regain track 
(seconds) 
Distance from track at 
pump suction (feet) 


Time to regain track 
(seconds) 


Time to regain track 
(seconds) 


Distance from track at 
torpedo tube entry 
(inches) 





Time to regain track 
Profile (seconds) 


Table 7.4. AUV distance from track under various cross-body flow (CBF) experiment conditions. 


The results arrived at in these experiments provide useful insight into the algorithms 


implemented in this thesis. The high-resolution buoyancy model, the wave motion simulation and the 


turbulent flow field simulation appear to be accurate and give consistent results which are in line with 


expectations. On the other hand, the experiments also demonstrate that the control algorithms which 


use doppler sonar input for cross-body flow measurement need to be tuned. The virtual environment 


thus provides a useful tool for control law testing, which can be further improved by incorporation of 


results from in-water validation tests. 


SUMMARY 


Experiments are a useful tool in any researcher's repertoire. They serve to verify the theories 


upon which technological innovations are based. This chapter presents the design of experiments that 


are performed in simulation and used to test the models developed in this thesis. The experiments 


address testing of the high-resolution buoyancy model, the wave motion simulation, turbulent flow- 


field simulation, and enhanced vehicle control using a doppler sonar employed as a cross-body flow 
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sensor. Additionally, design of experiments and the metrics used to measure results are discussed to 
provide the reader with a good understanding of what success is based on. These experiments are a 
useful means to rigorously test the Phoenix AUV dynamics model. The simulation results give hard 
data demonstrating the stability and accuracy of the hydrodynamics model and associated cross-body 


flow control laws. 
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VIII. CONCLUSIONS AND RECOMMENDATIONS 
A. CONTEXT 


This thesis has taken an in-depth look at methods of modeling environmental effects in a 
virtual environment. The net result is a virtual environment for the NPS Phoenix AUV which is more 
robust and better simulates the environment for which the AUV is being designed. These 
improvements are aimed at enhancing the SBD process, allowing engineers to rigorously test the 


performance of AUV systems prior to deployment in the vehicle. 


B. RESEARCH CONTRIBUTIONS AND CONCLUSIONS 


Throughout this thesis the intention has been to provide solutions to real-world problems. 
With that in mind, even simulation results provide useful contributions to the modeling community 
along with interesting experimental results for those concerned with autonomous robot simulation. 
The simulation enhancements include a high-resolution buoyancy model for wave simulation, an 
extensible body-induced flow methodology, and an approach to platform-independent distributed 
Simulation environments. 

The high-resolution buoyancy model divides the modeled vehicle into fifteen separate 
sections. Each one is then evaluated for its contribution to the overall vehicle buoyancy. This 
approximation gives an accurate representation of vehicle posture at shallow depths in various sea 
States. It proved to be quite useful when evaluating vehicle operation in various broach postures. Once 
fully submerged, at a depth where no portion of the vehicle is consistently exposed, its more accurate 
modeling characteristics were less apparent, again as expected. The high-resolution buoyancy model 
is a needed improvement with no noticeable consequence in terms of real-time performance. 

The ability to test AUV control in various sea states also turned out to be a significant 
improvement in vehicle modeling. The effects of wave motion come into play in shallow-water 
operations as well as during submarine docking evolutions. At shallow the forces of wave motion 
cause changes in vehicle velocities, accelerations and buoyancy. These factors need to be considered 
when fine-tuning control algorithms. They bring to light possibilities of over-sensitve control laws 
which can cause vehicle hunting and instability. During docking evolutions at submarine periscope 


depth, wave movement is also a factor. Although increasing depth for this type of operation reduces 
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wave-induced forces, they are still present and need to be dealt with. 

Another improvement in functionality of the virtual environment is the ability to simulate 
body-induced flow forces. The methodology used for this simulation is completely extensible. As 
researchers desire to change flow conditions, a simple data file replacement can import the new flow 
field into the virtual environment. By bracketing the submarine docking problem with worst-case and 
best-case flow instability, simulation results indicate that a feasible solution exists. A slight 
modification to current torpedo tube door mechanisms might thus provide an avenue to AUV 
recovery by naval submarines. 

The use of a doppler sonar to determine cross-body flow is also evaluated. This type of sensor, 
having the ability to provide speed over ground or speed through the water, enabled enhanced AUV 
control in complex flow fields. Its employment allows the robot to predict and compensate for 
movement instability using real-time flow condition feedback. Initial evaluation of doppler sonar 
demonstrates that the sensor, when properly used, provides irreplaceably valuable inputs for vehicle 
control. 

Finally, this thesis shows that platform-independent 3D real-time simulations are possible. 
The use of platform-neutral programming languages coupled with the rapidly increasing performance 
of personal computers has brought the ability to run complex distributed simulations anytime, 
anywhere. As network bandwidth continues to improve and PC performance is enhanced, platform- 


independent simulations will continue to get better and become more popular. 


C. RECOMMENDATIONS FOR FUTURE WORK 


On the technological frontier there are always things to do. Breakthroughs in technology 
happen at an amazing rate, with each new discovery bringing a new piece of gear or programming 
paradigm to light. As these developments occur it will continue to be necessary to thoroughly test and 
evaluate new technologies. The virtual environment is the ideal place for testing potential AUV 
hardware and software. 

This thesis falls short in the test and evaluation of the modeling technology proposed due to 
the lack of in-water tests. To remedy this situation, a series of tests need to be conducted to validate 


both the wave model and the complex body-induced flow interaction algorithm. These additions to 
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the virtual environment provide exceptional insight into vehicle behavior, but these results need not 
be broadly accepted until all doubt is laid to rest through validating in-water tests. 

Another area for future consideration involves both the execution level code and the dynamics 
code. The current versions of these programs use standard British units. Yet the DIS protocol requires 
metric units in its broadcast standard. This difference caused some inaccurate results during the 
prototyping stages. In some cases formulations appeared to be correct but unit differences caused 
erroneous results. After extensive troubleshooting all units were corrected and the results verified. For 
future development a single set of units (metric since DIS requires it) needs to be implemented in 
both the execution level code and the dynamics code. 

This thesis also proposes that a doppler sonar be used as a cross-body flow indicator onboard 
the Phoenix AUV. The simulation model for the doppler sensor used in this thesis was a simple one, 
lacking any noise distribution. Nonetheless, simulation of such a sensor demonstrates it can provide 
significant control enhancements. Further work is needed in simulation enhancement. Comparisons 
need be made between perfect data and expected (noisy) real-world data. As the NPS AUV research 
group moves towards the third incarnation of the Phoenix AUV it will be interesting install and test 
the DS30 doppler sonar. An instrument of this nature will likely enable very precise control of the | 
robot in dangerous operating environments. 

Another useful extension for robot development will be the integration of a depth-sensing 
model coupled with real-world terrain topology (Leaver, 1998). It is also useful to move the virtual 
world into the domain of testing sensor and effector performance in various acoustic environments. 
This 1s a significant step forward from the generic environment testing currently performed, enabling 
researchers to test equipment in a virtual Monterey Bay, then test in the real bay. It will likely 
eliminate errors normally attributed to environmental considerations. 

Other sensors to be enhanced in virtual simulation are the ST725 and ST1000 sonars. These 
sonars were modeled using several scan modes, employed in numerous different execution level 
tactics by (Davis, 1996). While the modes are accessible to all for low-level control, a simplification 
Is required allowing for easier scan mode selection. Addition of manual steering along a true bearing 
during the final stages of thesis testing added a new sensor value: lateral range (and range rate) to the 
submarine maintaining steady course and speed. An enumeration of all sonar modes and their addition 


to the execution command language will be useful in future tactic development. 


Se 


Animation is a vital part of any virtual environment simulation. Helping humans visualize the 
interactions taking place in the environment. It is one of the key reasons virtual simulations are even 
created. The Phoenix AUVs virtual environment is an irreplaceable resource. Continued use of virtual 


environment visualization and experimental validation will continue to provide invaluable insight. 
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APPENDIX A. VIRTUAL ENVIRONMENT C++ CODE 


1. UUVBody.C Excerpt 


ee (Sif Pipa er ο ο η η η η η 1 11// 


/ * 
Program: 


Description: 


Revised: 
System: 
Compiler: 


Compilation: 


Author: 


EOM Revisions: 


Dissertation: 


Advisors: 


References: 


UUVBody.C 


Six degree-of-freedom underwater vehicle hydrodynamics 
based on Healey model 


24 February 98 
Irix 5.3 
ANSI C++ 


irix» make UUVBody.o 
irix» CC UUVBody.C -lm -c -g +w 


-c == Produce binaries only, suppressing the link phase. 
+w == Warn about all questionable constructs. 

Don Brutzman brutzman@nps.navy.mil 
Code UW/Br 

Naval Postgraduate School 408.656.2149 work 
Monterey CA 93943-5000 408.656.3679 fax 


Jeff Riedel, FEB 97: removed extra cross-body flow terms 
Kevin Byrne, FEB 98: high-resolution buoyancy, cross-body flow 


Brutzman, Donald P., A Virtual World for an Autonomous 
Underwater Vehicle, Ph.D. Dissertation, Naval Postgraduate 
School, Monterey California, December 1994. Available at 
http: //www.stl.nps.navy.mil/~brutzman/dissertation/ 


Brutzman, Donald P., Software Reference: A Virtual World 
for an Autonomous Underwater Vehicle, technical report 
NPS-CS-010-94, Naval Postgraduate School, Monterey 
California, December 1994. The accompanying public 
electronic distribution of this reference includes source 
code and executable programs. World-Wide Web (WWW) 
Uniform Resource Locator (URL) is 

http: //www.stl.nps.navy.mil/~auv 


Dr. Mike Zyda, Dr. Bob McGhee and Dr. Tony Healey 


Healey, A.J. and Lienard, D., "Multivariable Sliding Mode 
Control for Autonomous DIving and Steering of Unmanned 
Underwater Vehicles," IEEE Journal of Oceanic Engineering, 
ОВЕНОТ ООО 1993, рр. 327-339. 


Yuh, J., “Modeling and Control of Underwater Robotic 
Vehicle," IEEE Transactions on Systems, Man and Cybernetics, 
vol. 20 no. 6, November/December 1990, pp. 1475-1483. 


Press, William H., Teukolsky, Saul A., Vetterling, 

William T. and Flannery, Brian P., "Numerical Recipes in C," 
second edition, Cambridge University Press, Cambridge 
England, 1992. 


Marco, David, "Autonomous Control of Underwater Vehicles 
and Local Area Maneuvering," Ph.D. dissertation, Naval 
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Postgraduate School, Monterey California, September 1996. 


Fossen, Thor I., Guidance and Control of Ocean Vehicles, , 
John Wiley and Sons, Chichester England, 1994. 


Bacon, Daniel Keith, Jr. "Integration of a Submarine into 
NPSNET," Master's Thesis, Naval Postgraduate School, 
Monterey, California, September 1995. Available via 
http://www.npsnet.nps.navy.mil/npsnet/publications.html 


Status: Equations of motion tested satisfactorily, 
verification against in-water tests remains. 
Added buoyancy and center-of-buoyancy changes at surface 
based on Dan Bacon's thesis work. 
Housekeeping: move utilities to math utilities.c 


Future work: Comments and suggestions are welcome! 
τ. 
ο ο η η η ОООО υ ВЫНОС А 
[/[ 8h Excerpt Follows RARER SS 
//---------------------------------------------------------------------------- 2 
void UUVBody:: integrate equations, of motion () 
( 
int MAX ACCELERATIONS_EXCEEDED = FALSE; 
current_uuv_time = AUV_time; 
double dt = current_uuv_time - time_of_posture_value (); 
if (dt < 070) // mission clock was reset, rezero the dynamics model 
( 
current uuv,. time - AUV time; 
set time of posture (AUV time); | 
set velocities (0.0, 0.0; 2050750 90 0D O O) 
set_accelerations (0.0, 0.0, 0.0, 0.0, 0.0, 0); 
dt = 020; 
ΤΌ 
V = 0.0; 
W 2 0707 
P = 020; 
O = 026; 
ая 2209507 
) 
double rho2 ="rho / 2.0; 
double L2 - μι” ος 
double L3 ΠΤ 5Ο; 
double L4 = t Dno pU 
double L5 = О УИА: 
// note that sign is not preserved in the following squared variables 
i in order to present consistent naming with Healey reference paper. 
£T To preserve sign, use (U * fabs (U)) etc. 
double P2 = P * P; 
double Q2 Ξ ο κο 
double R2 = R * R; 
// double U2 = W w Wa 
double V2 = V * V; 
double W2 = W * W; 
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// calculate world coordinate posture rates, use holding variables for speed 


double PHI - phi. value ( Е; 
double THETA - theta value (); 
double PSI - psi value (07; 
double sinPHI = О | PHI ); 
double cosPHI — (ee { PHI ); 
double sinTHETA = sin ( THETA ); 
double cosTHETA = cos {( THETA ); 
double sinPSI = Sin { PSI ); 
double cosPSI COS PSI ); 
// clamp inputs to max values allowed in hydrodynamics coefficients file - // 
if (MAX RPM » 0.0) 
( 
clamp (& AUV port rpm, -MAX RPM, MAX RPM, TAUV_peore, rpm"); 
clamp (& AUV_stbd_rpm, -MAX_RPM, MAX RPM, "AUWEStbd rpm^"); 
) 
if (MAX PLANE » 0.0) 
( 
clamp (& AUV delta planes, -radians (MAX PLANE), radians (MAX PLANE), 


"AUV delta planes"); 

ds (MAX RUDDER > 0.0) 

| clamp (& AUV delta rudder, -radians (MAX RUDDER), radians (MAX RUDDER), 
"AUV delta rudder"); 

i (MAX THRUSTER > 0.0) 


clamp(& AUV bow lateral, -MAX THRUSTER,MAX THRUSTER,"AUV bow lateral"); 
clamp(& AUV stern lateral, -MAX THRUSTER,MAX THRUSTER,"AUV stern lateral"); 
clamp(& AUV bow vertical, -MAX THRUSTER,MAX THRUSTER,"AUV bow vertical"); 


clamp(& AUV stern vertical,-MAX THRUSTER,MAX THRUSTER," AUV stern vertical"); 
) 


// finish initializations - - - - - - ------------- ------// 
double delta_planes_stern AUV_delta_planes; 
double delta_planes_bow - AUV_delta_planes; 
double delta_rudder_stern AUV_delta_rudder; 
double delta_rudder_bow ~ AUV_delta_rudder; 


// Zero ordered thruster values if no thrusters present 
AUV_bow_lateral *= THRUSTERS; 
AUV stern lateral *- THRUSTERS; 
AUV bow vertical  *- THRUSTERS; 
AUV stern vertical*- THRUSTERS; 


// double EPSILON - epsilon (); // no longer used in revised model 


f [ko e e ek ke ek e kk ke e ж] асу for Wave Model 

//Moved Variable definition for visibility throughout both models 
double sway integral 
double heave integral 
double pitch integral 
double yaw integral - 
double roll integral 
double surge integral - 
double U cf x; 


. 
t 


# 


O O O O O O 


, 


# 


=e 


O O O O O O 


`. 


1f (WAVE_BOUYANCY_MODEL == 0) { 
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// - - - - == - = = kk = = - o n M “πὶ 


// calculate neutral buoyancy using center of buoyancy near surface - - - // 
ΠΕ (AUV_z <= H / 2.0) /* transitlon, calculate broach extent */ 
( 

Jf (AUV_z >= -(H / 2.0)) /* broach region, reduce buoyancy х / 


revisedBuoyancy = Buoyancy * (AUV_z + H/2.0)/ H; 


else revisedBuoyancy = 0.0; /* completely out of the water 7 
) 
else revisedBuoyancy - Buoyancy; /* » H/2, no broach, normal submerged  */ 
/* = "uL L.x.l-zuwi^-es--—EEWE EB г л τα, 
This picture shows the condition (AUV_z == H / 2.0) which is the 
transition point above which revisedBuoyancy begins to drop off. 
revisedBuoyancy will = 0 when (AUV_z <= - H / 2.0) 
Severe buoyancy changes result when AUV position magically begins 
at depths so shallow that the AUV is initially above the surface. 
-Z 
| 
| 
- - H 
= =н? 
| 
0 Ο -------- surface ~~~~~~~~__ LLL TAA 
| (| |N 
+ + H/2 | AUV Z = H/2 | \ 0 
| ( | | / 0 
| + H (| | / 
+Z 


depth down (positive increasing z) 


// if boat is broaching and pitch THETA is positive, perform an approximate 
// calculation of how center of buoyancy CB moves back towards stern ` 


// nose_length is defined in UUVmodel.H and stays fixed 


if (I TrrTA — 0 0) || su = -- н ο) 
( 
revised X B - x B; // prevent divide-by-zero case and too-deep case 
) - 
else if (THETA > 0.0) 
( 
surface length - AUV z / SinTHETA; 
} 
else if (THETA < 070) 
( 
surface length - AUV z / (- sinTHETA); // roughly symmetric fore+aft 
) 
else 
( 
cout «« "Unexpected case in revised CB calculation!" «« endl; 
revised X B - x B; // prevent divide by zero case 
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if ((THETA !- 0.0) && 


(surface length « nose length) 
// move x_CB aft (fwd) but only if nose 


& & 
(stern) broaches the 


revised x B - x B- (nose length - surface length) 

) 

if (TRACE || TRACE EOM || (revisedBuoyancy != Buoyancy) ) 

( 
cout «« "revisedBuoyancy = " «« revisedBuoyancy «« ", "; 
cout «« "Weight s " «« Weight WE 
cout << endl; 
cout << " surface_length = " << surface_length << ", "; 
cout << "nose_length = " << nose_length E 
cout << "revised_x_B = " << revised_x_B << endl; 


) 


(AUV 


2 <= НОУ СО 
surface 


CXSIDnTHETA 7042505 


᾽ν... ..... УУЛУ ο η ldd tlll 


// integrate drag forces over the vehicle 
// corresponding to cross-body flow. 


double dx; 


// traverse longitudinal centerline: 


БО (int x index = 0; 


( 


dx = fabs (xx [x index] - xx [x_index + 1]); 
U_cf_x = sqrt ( square (V + xx [x index] * R) 
+ square (W - xx [x index] * Q)); 
if (U cf x » 1.0E-6) // arbitrary small non-0 minimum 


( 


sway integral += 


// removed from model 


7 


heave_integral += 


// removed from model 
/ / 


pitch integral -- 


// removed from model 
of 


rho2 * 


( C_dy * hh [x_index] 
* square ((V + xx 


+ C_dz * bb [x_index] 
* square ((W - 


* (V + xx [x index] ои“ 


rho2 * ( 


C-dy * hbpwixecaindesx] 
* square ((V + xx 


+C d2 ΕΕ (x index] 
* square ((W - xx 
* (W - xx [x index] 


* Q) * 


HO 2 eo ( 


C_dy * hh [x_index] 
* square ((V + xx 


+ C_dz * bb [x index] 
* square ((W - xx 


* (W - xx [x_index] 


чо) 


“(б 


Use cross-sectional slices. 


index through x coordinate arrays 
x 1ndex « cross, sections-1; x index ++) 


[x index] * кууш) 


хх [х_1паех] 


TEM 


Сах "OU "C EEG 


(x index] * R)) 


[x index] 


το) 


dx Z OD (Oye Ses 


[x_index] * R)) ) 


[x_index] 


Жору) 


// ^ note sign correction 


* xx [xw index p> dx 7 U Grew 


yaw integral += rho2 * ( C_dy * hh [х_1паех] 
* square ((V + xx [x index] * R)) ) 

// xemoved from model * C dz * bb [x index] 
үү * square ((W - xx [x index] * Q))) 


х (у + хх [x index] * R) 


* xx [κ indek "ας U cE x; 
} 
} 


if (TRACE || TRACE_EOM) 
{ 
Gout << "cx = " << ах << "USCI c TM Όμος 
<< ", sway integral = " << sway integral << endl; 
cout << "dx s "Gee dx ο Ὁ υ ορ ιτ == U Cfa 
«« ", heave integral - " «« heave integral «« endl; 
cout << “ds = m =< dx < Chex X e rx 
<< ", pitch_integral = " << pitch_integral << endl; 
Cout << *dx = " << dx << ", U-cf x = W<< U Cr X 
«« ", yaw integral - " «« yaw integral -«« endl; 


) 


) // end old bouyancy model 


else if (WAVE BOUYANCY MODEL -- TRUE) ( 
int in sub flow field = 0; 
int pw. flowfield x[cross sections]; 
int pw flowfield r[cross. sections]; 


//required variables for piecewise calculations of wave motion effects 


double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 


pw AUV x[cross sections]; 

pw AUV y[cross sections]; 

pw. AUV z[cross. sections]: 

pw nose length[cross sections]; 

pw surface length[cross. sections]; 
ον dx[cross. sections]; 

pw revised x B[cross. sections]; 
pushup[cross. sections]; 

pw revisedBouyancy[cross sections]; 
x difference; 

y difference; 

z difference; 

AUV TTube z difference; 

AUV SUB Course difference = 0 
grid x difference = 0.0; 
grid r difference = 0.0; 

flow force direction[cross. sections]; 

K waves - 0.4; //This is a factor used to reduce wave effects. 
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Otherwise 


vehicle goes unstable. 


double 
double 


temp doppler stw и Do 
temp doppler stw v O20; 


оп 


Vector3D U waves[cross. sections]; 


Vector3D pw UVW; 
reference 


//Holds piecewise flow velocities in AUV frmae of 
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Vector3D flow force magnitude[cross sections]; //This holds x-dot, y-dot, z-dot in 
sub ref frame 


Hmatrix flow rotation matrix; //This is used to move flow vector from 
the sub's (ft/sec) 


//Additions to the equations of motion 


double flow. field sway integral 
double flow field. surge integral 
double flow field heave integral 
double flow. field roll integral 
double flow field pitch integral 
double flow field yaw integral 


if 


) 


l H H H H I 
со O O O O O 
O O O O O O 


`. 


(SUBMARINE_DOCKING == TRUE) ( 


//Check to se if AUV is in the influence field of the submarine 
//This conversion uses 0.3048 meters per foot or 3.281 ft per meter 


x difference - (AUV x - submarine x); 
y difference - (AUV y - submarine y); 
z difference = (AUV z - submarine σ); 


//The order of AUV and TT is reversed to get sign correct since +z is down 
AUV TTube z difference - torpedotube z - AUV z; 


//All box calculations are in feet, here we convert to meters and 
//then compare 
//The 15in y calc accounts for sub diameter of 30 ft, radius - 15 ft 


if ((fabs(x difference)) «- (flowfieldbox length * FLOWFIELDLENGTH )  && 
(fabs(y difference)) «- (flowfieldbox width * FLOWFIELDWIDTH + 15.0 ) && 
(fabs(z difference)) «- (flowfieldbox height * 40.0 ) { 


//set flag to perform piecewise calculations 
in_sub_flow_field = 1; 


//calculate difference in AUV and sub course + speed 
AUV_SUB_Course_difference = submarine_course - AUV_heading; 


EE 7end of if in flow field 
//end if SUBMARINE DOCKING 


//Loop through body to Initialize all Arrays, perform piecewise calculations 


for (int x index = 0; x index «- cross sections - 1; x_index++) 
( 

pw dx[x index] = fabs(xx[x index] - xxí(x index + 1]); 

1£ (x_index == 0) { 


pw dx[x index]/2.0; 


pw nose length[x index] 
) 
else ( 


pw nose length[x index] pw dx[x index]/2.0 - pw nose length[x index - 1] + 


pw dx[x index - 1]/2.0; 


AUV 


) 

//Calculate pushup - the amount this sections pw. AUV z differes from the overall 
pushup[x index] - (xx[x index) « pw dx[x index]/2.0) * sinTHETA; 

//Calculate pw. AUV z 


pw AUV z[x index] - AUV z - pushup[x index]; 


//Here we perform all calulations for piecewise flow field forces 
//if AUV is in sub torpedotube area 


95. 


if (in sub flow ye lop s TRUR) { 


//Calculate an exact x & y for each section 
pw. AUV x[x index] » AUV x + (sin(90 - AUV SUB, Course difference) * 
(xx[x index] * pw dx[x index]/2.0)); 


pw AUV y[x index] -» AUV y * (sin(AUV SUB Course difference) * 
(xx[x index] -* pw dx[x. index]/2.0)); 


//Translate the x and y into grid coordinates based on position relative to sub 
//this takes position in feet and gives diff in ft 


grid x difference Ξξ ((double)submarine x - pw. AUV x[x index]l); 
grid r difference - sqrt ((pow((double)submarine y - pw AUV y[x index], 2)) - 
(pow((double)submarine z - pw. AUV z[x index], 2))); 


//Assuming each integer differnce equals one foot, this translates the difference 

//between sub and auv (x,y) into a coordinate in the grids reference. The 

//grid starts with (0,0) at the bow and (720, 0) at the stern. The center ofthe 
sub ; 

// is actually at grid position (360, 0). 

if (grid x difference >= 0) { 


pw flowfield x[x index] = 360 + (int)(2 * grid x difference); 
) 
else ( 

pw flowfield x[x index] = 360 + (int)(2 * grid x difference); 


) 


//Here 15 is subtracted to account for submarine radius (15 ft 
segments) 


pw flowfield гріх index] » (int)((grid r difference - 15.0) * 2.0); 


ЗОЗ; 


//Check to make sure pw flowfield x and y are valid 
if ((pw flowfield x[x index] »-  FLOWFIELDLENGTH - 1) || 
(pw. flowfield x[x index] « 0)) { 


if (TRACE) ( 
//print error message 
cout «« " kk kk kk kk kk kk kk k kk kk k kk k kk k kk kk kk kk k kk kk kk k kk k η << end1 


<< "pw flowfield x[x index] for AUV section " << x index 

«« " was calculated as " «« pw flowfield x[x index] «« endl; 
cout «« "Submarine X - " «« submarine x << " ft Submarine y - " 

«« submarine y «« " ft" ««endl 

«« "pw AUV x = " «« pw AUV x[x index] «« ' ft pw AUV y - " 

<< pw AUV y[x index] << " ft" 

«« endl; 


cout «« "Value reset to 360" «« endl; 
j 
//Reset the values to middle of grid 
pw flowfield x[x index] = 360; 
) 


if (pw flowfield r[x index] »- FLOWFIELDWIDTH - 1) ( 
if (TRACE) { 


//print error message 
cout << MO oe e e ce oe ee ee ode oe ce oe ode ce ehe ode ce oe oce oe oe oe cede oe oe cede cde conde ode ode coe ode ode ode oce cheek «« endl 


«« "pw flowfield r[x index] for AUV section " «« x index 
<< " was calculated as "| << pw_flowfield_r[x_index] << endl; 
cout << "Submarine X = " «« submarine x << " ft Submarine_y = " 


<< submarine_y << " ft" <<endl 
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3)) 


offset 


* knots 


E 


) 


«« "pw AUV x - " «« pw AUV x[x index] << " ft pw. AUV y = " 
«« pw AUV y[x index] «« " ft" 
«« endl; 

cout << "Value reset to l ft from hull" << endl; 


} 


//This case is reached most when AUV hits hull Therefore to keep flow 
//force consistent I reset the flow field index to 1, or 6" from hull 
//Reset the value to next to hull 

pw. flowfield r[x index] = 60; 


else if (pw flowfield r[x index] « 0) ( 


if (TRACE) ( 


//print error message 
Wc k k k k kk ἈΚ xk xk k Yk k k Kk * * * k kk k * k k k Kk Kk kk k xk kk k k k k kk k k * X 0 x u << endl 


cout «« 

«« "pw flowfield r[x index] for AUV section " «« x index 

<< " was calculated as " << pw flowfield r[x index] «« endl; 
cout << "Submarine X - " «« submarine x << * ft Submarine y - " 

<< submarine y << " ft" <<endl 

«« "pw AUV x = " «« pw AUV x[x index] << " ft pw AUV y - " 

«« pw AUV y[x index] «« " ft" 

«« endl; 


cout << "Value reset to 1 ft from hull" << endl; 
} 
//This case is reached when AUV hits hull Therefore to keep flow 
//tforce consistent I reset the flow field index to 1, or 6" from hull 
//Reset the value to next to hull 
pw flowfield r[x index] - 1; 


//Determine which flow grid to use based on pw, AUV z and selected model 
if (((fabs(AUV TTube z difference) «- torpedotube height) && ( FLOW FIELD MODE == 


|| (FLOW FIELD MODE == 2)) { 


//the direction should always be submarine course + flow field direction 


//The flow magnitude here is converted to ft/sec by multiplying by 
/* 
£t/sec = knots * 2000 yds/hr* 93 ft/yd * nr760 min^* min/60 sec = 1.667 


//Now decide which level of the tube flow fields to use 
if (AUV TTube z difference > 3.0) { 
//The AUV is in the above tube zone 


//Next select the appropriate speed matrix 
switch ((int) submarine speed) ( 
case 1: 
flow force direction[x index] - submarine course + 


abovetubelevellktgrid[pw flowfield x[x index]] 


[pw flowfield r[x index]].direction; 


flow. force magnitude[x index].setValue 


(abovetubeleveliktgrid[pw flowfield x[x index]] 
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[pw flowfield r[x index]].x magnitude * 1.667, 
abovetubelevellktgrid([pw flowfield x[x index]] 
[pw. flowfield r[x index]].y magnitude * 1.667, 
abovetubelevellktgrid([pw flowfield xí(x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 

break; 

case 2: 

flow force direction[x index] - submarine course - 

abovetubelevel2ktgrid[pw flowfield x[x index]] 


[ον flowfield rí([x index]].direction; 
flow. force magnitude[x index].setValue 


(abovetubelevel2ktgrid[pw. flowfield x[x index]] 
[pw flowfield rí[x index]].x magnitude * 1.667, 
abovetubelevel2ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].y magnitude * 1.667, 
abovetubelevel2ktgrid([pw flowfield x[x index]] 
[pw f£lowfield r[x index]].z magnitude * 1.667) ; 

break; 

case 3: 

flow force direction[x index] - submarine course + 

abovetubelevel3ktgrid[pw flowfield xíx index]] 


[pw flowfield r[x index]].direction; 
flow force magnitude[x index].setValue 


(abovetubelevel3ktgrid[pw flowfield x[x index]] 
[pw flowfield rí([x index]].x magnitude * 1.667, 
abovetubelevel3ktgrid([pw flowfield x[x index]l] 
[pw flowfield rí[x index]].y magnitude * 1.667, 
abovetubelevel3ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 

break; 

default: 
cerr «« "The submarine is moving to fast for the AUV to dock with." 


«« endl; 
break; 
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else if (AUV TTube z difference » 1.0) ( 
//THe AUV is at the upper tube edge zone 


//Next select the appropriate speed matrix 
switch ((int) submarine speed) ( 
case 1: 
flow force direction[x index] - submarine course + 
uppertubelevellktgrid[pw. flowfield x[x index]] 


[pw flowfield r[x index]].direction; 
flow force magnitude[x index].setValue 


(uppertubelevellktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].x magnitude * 1.667, 
uppertubelevellktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].y magnitude * 1.667, 
uppertubelevellktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 

break; 

case 2: 

flow force direction[x index] - submarine course + 

uppertubelevel2ktgrid[pw flowfield x[x index]] 


[pw flowfield r[x index]].direction; 
flow force magnitude[x index].setValue 


(uppertubelevel2ktgrid[pw flowfieid x[x index]] 
[pw flowfield r[x index]].x magnitude * 1.667, 
uppertubelevel2ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].y magnitude * 1.667, 
uppertubelevel2ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 

break; 

case 3: 

flow force direction[x index] - submarine course + 

uppertubelevel3ktgrid[pw flowfield x[x index]] 


[pw flowfield r[x index]].direction; 
flow force magnitude[x index].setValue 


(uppertubelevel3ktgrid[pw flowfield x[x index]l] 
[pw flowfield r[x index]].x magnitude * 1.667, 


uppertubelevel3ktgrid[pw flowfield x[x index]] 
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[pw flowfield r[x index]].y magnitude * 1.667, 
uppertubelevel3ktgrid[pw. flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 
break; 
default: 
cerr «« "The submarine is moving to fast for the AUV to dock with." 


«« endl; 
break; 


) 


else if (AUV TTube z difference > -1.0) { 
//The AUV is in the center of the tube zone 


//Next select the appropriate speed matrix 
switch ((int) submarine, speed) ( 
case 1: 
flow force direction[x index] -» submarine course - 
centertubelevellktgrid[pw flowfield, x[x index]] 


[pw flowfield r[x index]].direction; 
flow force magnitude[x index].setValue 


(centertubelevellktgrid[pw flowfield x[x index]] 
"ον... ERO LOS ~ 1667, 
centertubelevellktgrid[pw_flowfield_x[x_index] ] 
[pw flowfield r[x index]].y magnitude * 1.667, 
centertubelevellktgrid([pw flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 

break; 

case 2: 

flow force direction[x index] = submarine course + 

centertubelevel2ktgrid[pw flowfield x[x index]] 


[pw flowfield r[x index]].direction; 
flow force magnitude[x index].setValue 


(centertubelevel2ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].x magnitude * 1.667, 
centertubelevel2ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].y magnitude * 1.667, 
centertubelevel2ktgrid[pw flowfield x[x index])] 


[pw flowfield r[x index]].z magnitude * 1.667) ; 
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break; 
case 3: 
flow force direction[x index] - submarine course + 
centertubelevel3ktgrid[pw flowfield x[x index]l] 


[pw flowfield r[x index]].direction; 
flow. force magnitude[x index].setValue 


(centertubelevel3ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].x magnitude * 1.667, 
centertubelevel3ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].y magnitude * 1.667, 
centertubelevel3ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 
break; 
default: 


cerr «« "The submarine is moving to fast for the AUV to dock with." 


«« endl; 
break; 


) 


else if (AUV TTube z difference » -3.0) { 
//The AUV is in the lower tube edge zone 


//Next select the appropriate speed matrix 
switch ((int) submarine speed) ( 
case 1: 
flow force direction[x index] -» submarine course - 
lowertubelevellktgrid[pw. flowfield x[x index]l] 


[pw flowfield r[x index]].direction; 
flow force magnitude[x index].setValue 


(lowertubeleveliktgrid[pw  flowfield x[x index]l] 
[pw flowfield r[x index]].x magnitude * 1.667, 
lowertubelevellktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].y magnitude * 1.667, 
lowertubelevellktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 
break; 
Cases 


flow_force_direction[x_index] = submarine_course + 
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lowertubelevel2ktgrid[pw. flowfield x[x index]] 


[pw flowfield r[x index]].direction; 
flow force magnitude[x index].setValue 


(lowertubelevel2ktgrid[pw flowfield x[x index]] 
[pw. flowfield r[x index]].x magnitude * 1.667, 
lowertubelevel2ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].y magnitude * 1.667, 
lowertubelevel2ktgrid[pw. flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 

break; 

case 3: 

flow force direction[x index] - submarine course + 

lowertubelevel3ktgrid[pw flowfield x[x index]] 


[pw flowfield r[x index]].direction; 
flow force magnitude[x index].setValue 


(lowertubelevel3ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].x magnitude * 1.667, 
lowertubelevel3ktgrid[pw flowfield x([x index]] 
[pw. flowfield r[x index]].y magnitude * 1.667, 
lowertubelevel3ktgrid[pw flowfield x[x index]] 
ЖОЕЛ О а С о ОБСЕ ЈЕ. 

ргеак; 

default: 
cerr «« "The submarine is moving to fast for the AUV to dock with." 


«« endl; 
break; 


) 
else ( 


//The AUV is in the below tube zone 


//Next select the appropriate speed matrix 
switch ((int) submarine speed) ( 
case 1: 
flow force direction[x index] - submarine course + 


belowtubelevellktgrid[pw. flowfield x[x index]] 


[pw. flowfield, r[x index]].direction; 
flow force magnitude[x index].setValue 
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(belowtubelevellktgrid[pw flowfield x(x index]] 
(pw. £lowfield r[x index]].x magnitude * 1.667, 
belowtubelevellktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].y magnitude * 1.667, 
belowtubelevellktgrid([pw flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 

break; 

case 2: 

flow force direction[x index] -» submarine course + 

belowtubelevel2ktgrid[pw_flowfield_x[x_index] ] 


[pw_flowfield_r[x_index]].direction; 
flow force magnitude[x index].setValue 


(belowtubelevel2ktgrid[pw. flowfield x[x index]] 
[pw flowfield r[x index]].x magnitude * 1.667, 
belowtubelevel2ktgrid[pw flowfield x[x index]l] 
[pw flowfield r[x index]].y magnitude * 1.667, 
belowtubelevel2ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 

break; 

case 3: 

flow force direction[x index] -» submarine course + 

belowtubelevel3ktgrid[pw flowfield x[x index]] 


[pw flowfield r[x index]]l.direction; 
flow force magnitude[x index].setValue 


(belowtubelevel3ktgrid[pw flowfield x([x index]] 
[pw flowfield r[x index]].x magnitude * 1.667, 
belowtubelevel3ktgrid[pw flowfield x[x index]] 
(pw flowfield r[x index]].y magnitude * 1.667, 
belowtubelevel3ktgrid[pw. flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 

break; 

default: 
cerr «« "The submarine is moving to fast for the AUV to dock with." 


«« endl; 
break; 
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) //End of If that decides tube level 
) //End of if which decides flat/tube profile 
//This is the case of being in a flat plate field region 


else ( 


//Next select the appropriate speed matrix 
switch ((int) submarine speed) ( 
case 1: 
flow force direction[x index] = submarine course + 
nontubelevellktgrid[pw flowfield x[x index]] 


[pw flowfield r[x index]].direction; 
flow force magnitude[x index].setValue 


(nontubeleveliktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].x magnitude * 1.667, 
nontubelevellktgrid[pw flowfield, x[x index]] 
[pw flowfield r[x index]].y magnitude * 1.667, 
nontubelevellktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 

break; 

case 2: 

flow force direction[x index] -» submarine course + 

nontubelevel2ktgrid[pw flowfield x[x index]] 


[pw flowfield r[x index]].direction; 
flow force magnitude[x index].setValue 


(nontubelevel2ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].x magnitude * 1.667, 
nontubelevel2ktgrid[pw flowfield x[x index])] 
[pw flowfield r[x index]].y magnitude * 1.667, 
nontubelevel2ktgrid[pw flowfield x[x index]] 
[pw flowfield r[x index]].z magnitude * 1.667) ; 

break; 

case 3: 

flow force direction[x index] = submarine course + 

nontubelevel3ktgrid[pw flowfield x[x index]] 


[pw flowfield r[x index]].direction; 
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flow. force magnitude[x index].setValue 


(nontubelevel3ktgrid[pw. flowfield x[x index]] 
[pw. flowfield, r[x index]].x magnitude * 1.667, 
nontubelevel3ktgrid[pw. flowfield x[x index]] 
[pw flowfield r[x index]].y magnitude * 1.667, 
nontubelevel3ktgrid[pw flowfield x[x index]] 


[pw. flowfield r[x. index]].z magnitude * 1.667) ; 


break; 
default: 
cerr «« "The submarine is moving to fast for the AUV to dock with." 
<< endl; 
break; 
} 
) //end of else for flat plate region 
) //end of in flow field calculations 


//Check Bouyancy adjustment 
// transltion, calculate broach 


TÉ (pw AUV z[x index] <= H / 2.0) 
extent 
( 
if (pw AUV z[x index] >= -(H / 2.0)) // broach region, reduce buoyancy 
( 
pw revisedBouyancy[x index] -» (Buoyancy/cross sections) * (pw AUV z[x index] 
* H/2.0) /H; 
) 
else 
i 
= ОО // completely out of the water 


pw revisedBouyancy[x index] - 
) 
) 


else 


( 
// » H/2, no broach, 


pw revisedBouyancy[x index] - (Buoyancy/cross sections); 
normal submerged 


) 


//Global wave force effects in ft per second 


U waves[x index].setValue ( K waves * 
(SeaState[SEASTATE].H s * SeaState[SEASTATE] . freql*: 


(cos ( SeaState[SEASTATE].freq1*AUV time + 


SeaState[SEASTATE].wavelength*pw nose length[x index] ))) // + 
//SeaState[SEASTATE].H s * SeaState[SEASTATE].freq2* 


T (cos ( SeaState[SEASTATE].freq2*AUV time + 


ul 


SeaState[SEASTATE].wavelength*pw nose length[x index] )) + 
//SeaState[SEASTATE].H s * SeaState[SEASTATE].freq3* 


// (cos ( SeaState[SEASTATE].freq3*AUV time + 


y 


SeaState[SEASTATE].wavelength*pw nose length[x index] ))) 
*(cos (heading wave 1 - AUV psi)) 


, 
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0.0; 


K_waves * 
(SeaState[SEASTATE].H s * SeaState[SEASTATE].freql* 
(cos ( SeaState[SEASTATE].freq1*AUV time + 90.0 + 


SeaState[SEASTATE].wavelength*pw nose length[x index] ))) // + 
//SeaState[SEASTATE].H s * SeaState[SEASTATE].freq2* 
yy (cos ( SeaState[SEASTATE] .freq2*AUV_time + 90.0 
5 
SeaState[SEASTATE].wavelength*pw nose length[x index] )) + 
//SeaState[SEASTATE].H s * SeaState[SEASTATE].freq3* 
y (cos ( SeaState[SEASTATE].freq3*AUV time + 90.0 
"i 


SeaState[SEASTATE] .wavelength*pw nose, length[x index]))) 
*(cos (heading wave 1 - AUV psi)) 


Jm 


//At depth » 20 we reduce the wave motion effect linearly, deeper than 100' wave 
effect is negligible 

if (AUV z » 20.0) 

( 


U waves[x index].setValue ( U waves[x index][1] * ((100.0-AUV z)/100.0), 
0.0, 
U waves[x index]([3] * ((100.0-AUV z)/100.0) ); 


} else if (AUV_z > 100) { 
U_waves [x_index].setValue ( 0.0, 0.0, 0.0); 
} 


//Check for revised_x_B adjustment 

if ((ТНЕТА == 0.0) || (р АШУ 2[х_1пдех] >= н / 2.0)) 

( 

pw revised x B[x index] = xx[x_index] + (pw dx[x index]/2.0); // prevent 

divide-by-zero case and too-deep case 

) 

else if (THETA » 0.0) 

( 


pw surface length[x index] pw. AUV z[x index] / sinTHETA; 


) 
else if (THETA < 0.0) 
{ 


pw surface length[x index] pw AUV z[x index] / (- sinTHETA); 


) 


else 
( 
cout «« "Unexpected case in revised CB calculation!" «« endl; 


pw revised x B[x index] = xx[x_index] + (pw dx[x index]/2.0); // prevent divide 
by zero case 


) 


if ((THETA !- 0.0) && (pw surface length[x index] « pw nose length[x index]) && 
(pw AUV z[x index] «- H / 2.0)) 


// move x CB aft (fwd) but only if nose (stern) broaches the surface 


( 
pw revised x B[x index] = (xx[x index] * (pw dx[x index]/2.0)) - 
(pw nose length[x index] - pw surface length[x index]) * sinTHETA / 2.0; 
//cout «« "pw revised x B in case one(nose out) - " «« pw revised x B[x index]-« 


endl; 
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) 
else ( 
pw revised x B[x index] -  (xx[x index] * (pw dx[x index]/2.0)); 
//cout << "pw revised x B in case 2- " «« pw revised x B[x index]«« endl; 


) 


if (TRACE || TRACE EOM) 
( 


cout << "AUV Z - " << AUV_z «« endl; 

cout «« x index << " pw dx - " «« pw dx[x index] «« endl; 

cout << "xx - " «« xx[x index] «« endl; 

Cout << "sinTHETA = " << sinTHETA << endl; 

cout «« "pushup = " << pushup[x_index] << endl; 

cout << "pw_AUV_z = " << pw_AUV_z[x_index]<< endl; 

cout «« "pw nose length - " «« pw nose length[x index]«« endl; 

cout << "pw surface length - " «« pw surface length[x index]«« endl; 
cout << "pw_revisedBouyancy = " << pw_revisedBouyancy [x_index]<< endl; 
cout << "pw_revised_x_B = " << pw_revised_x_B[x_index]<< endl; 


} 
) //end for loop 
//Loop to sum up piecewise bouyancy and x_b effects 
revisedBuoyancy = 0.0; 
revised_x_B = 00; 
for (int x1 index = 0; x1 index «- cross sections - 1; х1 іпаех++) { 


revisedBuoyancy = revisedBuoyancy - pw revisedBouyancy[xl, index]; 


revised x B - revised x B -« ((xx[xl index] + pw_dx[xl_index]/2.0) - 
(pw revised x BÍ[x1, index])); 


) //end for loop 
revised x B - x B - revised x B; 


if (TRACE || TRACE EOM) 
( 


cout «« "revisedBuoyancy " << revisedBuoyancy << ", "; 
cout << "Weight = " << Weight Εμ; 
cout << endl; 

cout «« " surface length «« surface length << ", "; 
cout «« "nose length - " «« nose length -- s 
cout << "revised x B - " << revised x B «« endl; 


) 
Mmm ОУУ ο ο Ad 


// integrate drag forces over the vehicle - - - - - - --------- - -// 
// corresponding to cross-body flow. Use cross-sectional slices. - - - - -// 


//This section of code creates the rotation matrix which will be used later to 
//transform flow filed components from the sub's reference frame to the AUV's 
flow rotation matrix.set identity(); 

flow rotation matrix.rotate (submarine roll - AUV phi, 
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submarine pitch - AUV theta, 
submarine course - AUV psi); 


//This starts the summation of cross body drag forces. The following if statement 
//allows for 2 different modes of cross body calculations, one for a circular hull 
//and one for a square hull. The type of Hull is required to be defined in UUVmodel.H 


if (SQUARE HULL -- TRUE) ( 
// traverse longitudinal centerline: index through x coordinate arrays 
for (int x2, index - 0; x2 index «- cross sections - 1; x2 index*«*) ( 


//Calculate the effects of sub flow field 
mee cin sub flow field == ту 


//here flow forces are due to flow field + wave motion 
flow_force_magnitude[x2_index] = flow force magnitude[x2 index] - 
U waves(x2. index]; 


) 


else { 


//here flow forces are due to wave motion only 
flow force magnitude(x2. index] - U wavesí(x2. index]; 


//This gets U, V, W from (x-dot, y-dot, z-dot)*rotation matrix transpose 
pw UVW.setValue( flow rotation matrix * flow force magnitude[x2 index]); 


if (x2 index == 1), { 
temp_doppler_stw_u = pw_UVW[1]; 
temp_doppler_stw_v = pw_UVW[2]; 


// these integrals are for wave and flowinduced drag forces 
flow field sway integral += , rho2 * ( C dy * hh [x2 index] 
* pw UVW(2] * fabs(pw UVW[2])) 


* pw dx([x2, index]; 
flow field surge integral - 0.0; 


flow field heave integral += rho2 * ( C qz * pb [x2 index] 
* pw_UVW[3] * fabs(pw_UVW[3])) 
* pw_dx[x2_index]; 


flow field roll integral » 0.0; 


flow field pitch integral += rho29* 00 C dz * Do? index] 


х ри ОУН [3] * fabs(pw UVW(3])) 
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flow field yaw integral 


// these integrals are for 
sway integral += της; ; 
heave_integral += τος = 
оо: += rho2 * 
yaw_integral += rho2 * 


roll integral += 0.0; 


* xx [x2 index] * pw_dx[x2_index]); 


+= τ Г КС dy * hh [x2. index] 
* pw UVW[2] * fabs(pw UVW[2])) 


* xx [x2 index] * pw_dx[x2_index]; 


rigidbody velocity drag forces 
(C day * hh [x2-1ndex] 
* square ((V * xx [x2 index] * R )) ) 
* pw. dx [x2 index]; 
( C_dz * bb [x2_index] 
* square ((W - xx [x2 index] * Q))) 
* pw dx[x2 index]; 
( C.dz * bb [x2 index] 
* square ((W - xx [x2 index] * Q))) 


* xx [x2 index] * pw. dx[x2. index]; 


( C. dy * hh [x2. index] 
* square ((V + хх [x2 index] * R )) ) 


ж х [x2-index] * pw-dx[x2-index]; 


if (TRACE || TRACE_EOM) 

{ 
COL ---opwedsxix2erindex]'«e9"U cf x 2 "«« U ctf x 
<< ", Sway integral ^- " «« sway integral «« endl; 
ασια ο π᾿, υπ: index] << Ulcf x = " << U_cf_x 
«« ", heave integral - " «« heave integral «« endl; 
Cout << "Дх = " << ру_ах[х2_1пдех] <<", σεν  '" «« U cf x 
<< ", pitch integral - " «« pitch integral << endl; 
соц << "Дх Cn << pw dx[x2 index) << ", U_cf x = " << U cf x 
<< ", yaw_integral - " «« yaw integral «« endl; 


) 
) //end for loop 


) //End of the square hull case 


//This starts the round hull case of cross body drag 
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else ( 


// traverse longitudinal centerline: index through x coordinate arrays 
for (int x2 index - 0; x2 index «- cross sections - 1; x2_index++) { 
U cf x = sqrt ( square (V + хх [x2 index] * R) 


+ square (W - xx [x2_index] * Q)); 


if (U_cf_x > 1.0E-6) // arbitrary small non-0 minimum 


{ 


//Calculate the effects of sub flow field 
ifin sub flow field == I)i 


//here flow forces are due to flow field + wave motion 
flow force magnitude[x2 index] - flow,.force magnitude[x2 index] + 
U waves [x2 index]; 


) 


else ( 


//here flow forces are due to wave motion only 
flow force magnitude([x2.index] = U waves(x2. index]; 


//This gets U, V, W from (x-dot, y-dot, z-dot)*rotation matrix transpose 
pw UVW.setValue( flow rotation matrix * flow force magnitude[x2, index]); 


if (x2 index == I) { 
temp doppler stw u = pw_UVW[1]; 
temp doppler stw v - pw UVW[2]; 


// these integrals are for wave and flowinduced drag forces 
flow field sway integral += rtho2 * τσ ο πα index] 
* pw UVW[2] * fabs(pw UVW[2])) 


* pw dx[x2. index]; 


flow field surge integral - 0.0; 


flow field heave integral += ιο»; C. dz *bbSpx2ssndesx] 
* pw UVwW[3] * fabs(pw UVW[3])) 


* pw dx(x2. index]; 


flow_field_roll_integral = 0.0; 


flow_field_pitch_integral += rho2 * ( C dz * bb [x2_index] 
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ШЕСЕ х; 


ΕΤ χ; 


flow. field. yaw integral 


ρα [ο] ee 


* xx [x2 index] 


+= τος 7 


* pw UVW[2] * 


* xx [x2 index] 


асо hh 


fabs (pw. UVW[3])) 


* pw. dx[x2. index]; 


[x2. index] 
fabs (pw. UVW[2] )) 


* pw dx[x2. index]; 


// these integrals are for rigidbody velocity drag forces 


sway integral += rho2 
heave integral += rho2 
pitch integral += rho2 
yaw integral += кһо2 


) (HONG Of if (U cf x > 1.0E- 
if (TRACE || TRACE EOM) 
( 

cout << "dx = * << pw_dx[x2_ 


<< ", sway integral =" << 


«аж = " 
heave_integral = 


οσους “<< 
<< i^^ "1 << 
εσυ << "ах =" 
ΕΙ pitch integral =" < < 
cout (<< "dx = 


«« ", yaw integral m NE 


<< pw_dx[x2_ 


<< pw_dx[x2_ 


LNEC 25 


οι C ay shi jy o index] 


* square ((V + xx [x2_index] 


* (V + xx [x2 index] * 


(C dz ~ DOIR index] 


* square ((W - xx [x2_index] 


* (W - xx [x2 index] * 


* ( C dz * bb [x2. index] 


* square ((W - xx [x2 index] 


* (W - xx [x2 index] * 


* xx [x2 index] 


* ( C-dy * hh V [x2*32pdex] 


* square ((V * xx [x2 index] 


х (У + хх [x2 index] * 


* xx [x2 index] 


6) 


index] kan n Uef xs "<< 
sway_integral << endl; 
Index|) <<a, U cf k = T< 
heave_integral << endl; 
jndex]esco* U CE K SN 
pitch_integral << endl; 
index] << "U cf x= "x< 


yaw_integral << endl; 
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* pw dx[x2 index] 


ο ο 


R) pw dx[x2-index]| / 


Оуу) 


О) ры ах[ х2 index] 7 


оуу) 
Q) 


ΕΕ Χὶ 


ΕΓ 


R) 


* pw cx[x2 index] / U. cf x; 


User x 


Usct-x 


ОСЕ х 


ПКЕЕ x 


) //lend for loop 
) //End of the round hull case of cross body drag 


//Add effects of flow field integral's to eom integrals 


roll. integral 
surge integral - 


+ 


flow_field_roll_integral; 
flow_field_surge_integral; // unused 


sway_integral += flow field sway integral; 
heave integral += flow field heave integral; 
pitch integral += flow field pitch integral; 
yaw integral += flow field yaw integral; 


//set doppler velocities for speed through water in ft/sec 
doppler_stw_u = temp_doppler_stw_u; 
doppler_stw_v = temp_doppler_stw_v; 


) //end new bouyancy model 


ο ο. ο... ΑΛ ο ο ο ОООО fa E 


// debug section. selectively set sway/heave/pitch/yaw integrals to zero to 
/ / isolate problems. also see zeroing of rhs values. 


// sway integral = 0.0 
// heave integral 0 
// pitch integral 0 
57 yaw integral - 0.0; 


(e 


’ 
е 
# 


ΑΜ ΑΜΕΑ τα ο ο ο ο η, Ὁ Е 


// reduce efficiency if propellers operating astern - - - - - ------- yh 
double port_propeller_efficiency, stbd_propeller_efficiency; 


1f (AUV_port_rpm >= 0.0) port_propeller_efficiency 
else port_propeller_efficiency 


J. O 
X_astern_efficiency; 


if (AUV stbd rpm >= 0.0) stbd, propeller efficiency 
else stbd propeller efficiency 


1ο 
X astern efficiency; 


η ΕΕ η ελ ο ОООО А 
// calculate Equations of Motion right-hand sides 27 
ΜΕ αν. METUO UNI EUN ATE Л УУ О 

rhs [SURGE] = // Surge Motion Equation right hand side -------------------- // 


m.* ((V * R) =- (W * Q) + X G * (02 + R2) —- y G * P*Q = 2 G * P*R) 


64 Ια; ΙΕ; Ξτ:,; а о? 
t X rr * R2 + XA pr * P*R) 
+ rho2 * L3 * ( X wq * W*Q Κυ X vp * V*P «- X vr * V*R 
+ U*tQ* ( X uq delta, bow * delta, planes bow 


+ X uq delta stern * delta, planes stern) 


+ U*R * ( X ur delta rudder * delta rudder bow 
ΚΕ X ur delta rudder  * delta rudder stern) 


+ rho2 "τ: A VV <r F. WO 
+ U*V * ( X uv, delta rudder τ: delta rudder stern) 


+ U*W * ( X uw delta bow * delta planes. bow 
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*€ X uw delta stern * delta planes. stern) 


+ U * fabs (U) * ( uuvsdelta b delta. b 
* delta planes bow 
* delta planes. bow 


* X uu delta, s, delta s 
* delta planes stern 
* delta planes stern 


* X uu delta r delta r 
* delta rudder. bow 
* delta, rudder. bow 


* X uu delta r delta r 


* delta rudder stern 
* delta rudder. stern) 


- (Weight - revisedBuoyancy) * sinTHETA 

// EPSILON terms have been removed due to revised equations of motion 
// * rho2 * L3 * X qdsn * U*Q * delta planes stern * EPSILON 

// * rho2 * L2 * EPSILON * ( X wdsn * U*W * delta planes. stern 

if 


L7 + X dsdsn * U2 * delta_planes_stern 
n * delta planes stern) 


// X propulsion surge force (derived using expressions in Healey paper) 
// note that SPEED PER, RPM is associated with work of two propellors 


+ гһо2 * 12 * Cd0 * square (SPEED PER RPM) 


x 0.5 * ( AUV_port_rpm * fabs (AUV port, rpm) 
* port_propeller_efficiency 


* AUV stbd rpm * fabs (AUV stbd rpm) 
* stbd propeller, efficiency) 


// X resistance surge drag (derived using expressions in Healey paper) 


πο δρ * С або ^0 * fabs (U); 


ου - - ο η ο ο η η η Αη ЛУ ЛГУ ГГ УГ ГУ ГГ / ГГ //// 
if (TRACE || TRACE EOM || (rhs [SURGE] »- MAX SURGE)) // Surge TRACE 
{ 
cout << "* Surge terml=" << m * ((V * R) - (W * О) 
+ x С * (02 + R2) - y.G* P*QO ~- 2G * P*R)<< endl; 
cout << “term2=" << + rho2 * 4 * ( X pp * P2 + X qq * 02 
+ X Yr * Е2 ο εκτ бт ΕΕ) 
«« endl; 
cout << "term3=" << + тпо2 ος πα οι W'*O + X Vp * V*P + УЕ 
+ U*O * ( X_uq_delta_bow * delta_planes_bow 
+ X_uq_delta_stern * delta_planes_stern) 
+ U*R * ( X ur delta rudder * delta rudder. stern 
+ X_ur_delta_rudder * delta_rudder_bow) 
) 
<< endl; 
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Cout << "term4=" << T rHo2 * L2 * ( X NN O RO j ij X w * WZ2 
+ U*V * ( X uv delta rudder * delta rudder stern) 


+ U*W * ( X uw delta bow * delta planes. bow 
+ X uw delta stern * delta planes stern) 


+ U * fabs (U) * ( X.uu delta. b delta b 
* delta planes bow 
* delta planes bow 


-* X uu delta s delta s 
* delta planes stern 
* delta planes stern 


-* X uu delta r delta r 
* delta rudder bow 
* delta rudder. bow 


- X uu delta r delta r 
* delta rudder stern 
* delta rudder stern) 


«« endl; 

cout «« "term5-" «« - (Weight - revisedBuoyancy) * sinTHETA 
<< endl; 

cout << "term6,term7=" << "EPSILON terms, no longer used" 
<< endl; 


// cout << “termG=" - . τπος ους X qdsn * U*Q * delta_planes_stern 
// * EPSILON << endl; 


(Lv) 

// cout << “term7=" << rho2 * L2 * EPSILON * ( X wdsn * U*W 

"Ani * delta planes stern 
iod + X_dsdsn * U2 * delta_planes_stern 
V7 * delta_planes_stern) 
Zw «« endl; 


cout << "term8-" << + rho2 * L2 * C_d0 * square (SPEED PER RPM) 


* 7075 *—(--AUV"Dort rpm = fabs (AUV port rpm) 
* port_propeller_efficiency 


+ AUV_stbd_rpm * fabs (AUV_stbd_rpm) 
* stbd_propeller_efficiency) 
<< endl; 
cout << “term9=" << = rho2 |") G52)" Grd0 VU." tabs (U) 


<< endl; 


} 
η η η η ΑΜ ο... NENNEN ή. 
rhs [SWAY ] - // Sway Motion Equation right hand side ------------------- / 
m * (— (U * R) + (W “ο. 
+ y G * (p2 R2) 
= Z ο ο ο. RI 


ΠΟ; τ: ια * P*O + Y_qr TORR) 
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ΘΙ; D SUS P + Y_ur * U*R 
+ Y vq Ἢ + Y_ wp ΝΡ + Y_wr * W*R) 
t rho2.* L2 * ( ταν EE + Y vw η 
+ U*fabs(U) * Y_uu_delta_rb * delta rudder bow 
+ U*fabs(U) * Y uu delta rs * delta rudder. stern) 


- Sway integral 


+ (Weight - revisedBuoyancy) * cosTHETA * sinPHI 


(2.0 / (24.0 * 24.0)) // each thruster 2.0 lb per 24V signal squared 


* ( AUV_bow_lateral * fabs (AUV_bow_lateral) 
+ AUV_stern_lateral * fabs (AUV stern lateral)); 


pur C /7/77/7/7/77/77/7/77/77/7////7/7//777/7)77/77//02/7///77/7/7/7/7///////0/7/ 


if (TRACE || TRACE EOM || (rhs [SWAY] »- MAX SWAY)) // Sway TRACE 
{ 
cout «« "* sway termls" << тю * (- (U * R) * (W * P) 


sex G * (РИО) 
а; ме @ * (P2 * R2) 


το = HD QR 


«« endl; 
Powe << “term2=" << + rho? * 14 * ( Y pq ΡΟ + Y_qr * O*R) 
«« endl; 
Cout << "term3=" << + тол ли ыу кор * JU*P τ ΠΕ ΤΕ 
ΕΤΕΙ ΤΌ * Y wp * W*P + Y_wr W*R) 
<< endl; 
ους ες “term4=" << πο στ Ὁ NIS * Y vw ОМИ 
+ U*fabs(U) * Y uu delta rb * delta, rudder. bow 
* U*fabs(U) * Y uu delta rs * delta rudder stern) 
«« endl; 
BOULE “term5=" << - Sway integral «« " sway integral" 
<< епа1; 
EDUESCc “term6=" << * (Weight - revisedBuoyancy) * cosTHETA * sinPHI 
«« endl; 
eo ες "term7z" << СООР οσο 54.0} 
// each thruster 2.0 lb per 24V signal squared 
* (  AUV bow lateral * fabs (AUV bow lateral) 
* AUV stern lateral * fabs (AUV stern lateral)) 
<< endl; 


} 


ПАРТУ РИ / Г ЖИМИ AAA LA / / DISSI 


rhs [HEAVE] - // Heave Motion Equation right hand side -------------------- J 
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мт" (О ОЕ МИ Рух С. РИ ου υπο 


ΕΝ (PZ πο) 


*—rho2 Ες οἱ * P2 + орт ΡΕ 47 Xr πο 
* rho2 * L3 7*0 Nu "0709 + Z2 πο ЮР ο νο VÝR) 
* rho27*552 * UW π᾿ + Z_VV * V2 


+ ( U*fabs(U) * Z_uu_delta_b * delta_planes_bow ) 
+ ( О*Ғарѕ (Ч) * Z uu delta s * delta planes stern)) 


- heave integral 


+ 


(Weight - revisedBuoyancy) * cosTHETA * cosPHI 


// EPSILON terms have been removed due to revised equations of motion 


K m rho2 я тз z qn * U*O * EPSILON 

Ex xrho2 *-nL2 = ( Z_wn * U*W 

/ / * Z dsn * U*fabs(U) * delta planes stern) * EPSILON 

+ (2.0 / (24.0 * 24.0)) // each thruster 2.0 lb per 24V signal squared 
* ( AUV bow vertical * fabs (AUV bow vertical) + 


AUV stern vertical * fabs (AUV stern vertical)); 


ο η η ΑΟ ο ОТОС 


if (TRACE || TRACE EOM || (rhs [HEAVE] >= MAX_HEAVE) ) // Heave TRACE 
{ 
cout << "* heave terml=" << m * ( (U * О) - (V * P) =- x_G * (P * R) 
ΞΕ; ο. ο) 
+ zG * (P2 + Q2)) 
<< endl; 
cout << “term2=" << Tcrhos ^ Dd * 10 75D ΤΕ: FZ pr SOPIR 
+ Z rr * R2) == епаш: 
cout << "term3=" << + rho? ОЗО Спа «2070 το νο yP 
+ Zvr * V*R) << endl; 
cout << “term4=" << * rho2 * L2 (ВЫ 2 uw πμ) Ww 4 2 vv * V2 
* ( U*fabs(U) * Z uu delta b * delta planes bow ) 
* ( U*£abs(U) * Z uu delta, s * delta planes stern)) 
«« endl; 
poutece “term5=" << - heave integral «« " heave integral" 
«« endl; 
cout << "term6=" << + (Weight - revisedBuoyancy) * cosTHETA * cosPHI 
«« endl; 
Cout << "term7, term8=" << "no longer used" 
«« endl; 
Cout << "term9=" << + (2.0 / (224p0 s Ζ΄ 


// each thruster 2.0 lb per 24V signal squared 


* ( AUV bow vertical * fabs (AUV bow vertical) + 
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AUV stern vertical * fabs (AUV stern vertical) ) 
«« endl; 
) 
К ee 7 77/77 77/////////7////////////////////////l/ 
rhs [ROLL ] = // Roll Motion Equation right hand side -------------------- / 

ОК ОЕ ОГ π᾿ τ: ΡΕ НЧ ISV2-* 02 = R2) + I xz * P*Q 

— m * ( y_G * ( -U*Q + V*P) - z_G ( U*R = W*P)) 

Έπος το ο τε ραςςρεο εκσιτοΕ 


IE ο ο Ὁ ο tabs (2) 
+ Kp * Р ) // hovering roll drag 


τος ος πιο fabs(U)* PT + K ur * U*R +°K vq * V*Q 
+ K.wp * W*P + K wr * W*R) 
RO? L3 * ( K uyv * U*V + K vw * V*W 


- U*fabs(U) * 0.5 * ( K uu planes * delta planes bow 
* K uu planes * delta planes stern) 


- U*fabs(U) * 0.5 * ( K uu rudder * delta. rudder bow 
-* K uu rudder * delta rudder. stern)) 


//Added roll integral for square hull model 
* roll integral 


// expected: opposed plane directions ^ cause negation & cancellation 
+ (y G * Weight - y B * revisedBuoyancy) * cosTHETA * cosPHI 
- (zG * Weight - z B * revisedBuoyancy) * cosTHETA * sinPHI; 


// EPSILON terms have been removed due to revised equations of motion 
// + rho2 * L4 * K pn * U*P * EPSILON 


E rho2 * L3 * U*fabs(U) * K prop; // oversimplified, in error 


gu //////////40/077/77////7/777//7//777/7/7/7///7////////////7///7//////////// A 


if (TRACE || TRACE_EOM || (rhs [ROLL] >= MAX_ROLL)) // Roll TRACE 
( 
u "* roll terml-" «« - (Iz - LI y) * Q*R - І ху * P*R + I_yz * (Q2 - R2) 
+ I_xz * P*Q 
«« endl; 
cout << "term2=" << - m * ( y_G * ( -U*Q + V*P) - 2G * ( U*R - W*P)) 
<< end1; : 
πι: Cerm3s=" << + rho2 * L5 * ( K pq * P*Q + K_qr * Q*R 
+ K_pp * P * fabs(P) 
+ Kp * Pp ) // hovering roll drag 
<< endl; 


cout << "“term4=" << «- rho2 * Ld * ( K_up * fabs(U)*P + K_ur * U*R 


+ K vq *"V*O + K_wp * W*P 6 K wr * W*R) 
<< endl; 
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cour «« 


<< 


cout << 
<< 


cout << 
<< 


cout << 
<< 


// cout 
А 


;7-cout 
"un 

) 
ELI 


rhs 


η ή 


*term5=" << + ҺИН ОО Кал το VW 


- U*fabs(U) * 0.5 * ( K uu planes * delta planes, bow 
* K uu planes * delta planes, stern) 


- U*fabs(U) * 0.5 * ( K uu rudder * delta rudder bow 
+ K_uu_rudder * delta rudder stern)) 


// expected: opposed plane directions ^ cause negation & cancellation 
endl; 


"term6=" << « (y G * Weight - y B * revisedBuoyancy) * cosTHETA * cosPHI 
endl; 

"term7=" << - (z_G * Weight - z_B * revisedBuoyancy) * cosTHETA * sinPHI 
endl; 

"term8,term9=" << "EPSILON terms, no longer used" 

endl; 

<< MAterm8=" << + rho2°* L4 * Kopn *3USES GPEPSEIDLON 


<< endl; 

<< "term9-" << + rho2e* ο ~20"- fabs (Uwe? op 
<< endl; 

РРР ОИНИ ИИИ АНОН ο ο Ηλ. 
[PITCH] = // Pitch Motion Equation right hand side -------------------- ui 


= (I_x - Iz) * P*R + I xy * QO^*R - 1ї1_у> * Р*О - I xz * (P2 - R2) 


+ m * ( xG * ( =U*#Q + VP) - Z” CG + ( ZVIR |= W*Q)) 

* rho2 * L5 πο. πο ' + M_pr * P*R + M_rr * R*fabs (R) 
+ Ми оО 
+ M_qq * Q * fabs(Q)) // hovering pitch drag 


* rho2 * LA * ( M uq υο μου EM vr ~ VR) 
t rho2 * L3 ο ο οι ου ο ү лл ο 


+ U*fabs(U) * ( M uu delta. bow * delta planes bow 
- M uu delta stern * delta planes stern)) 


* pitch integral // note sign corrections to Healey pitch integral 


- (x G * Weight - revised x B * revisedBuoyancy) * cosTHETA * cosPHI 
- (z G * Weight - Z B * revisedBuoyancy) * sinTHETA 
+ (2.0 / (24.0 * 24.0)) // each thruster 2.0 lb per 24V signal squared 


// multiplied by respective moment arms 
// x_bow_vertical (+), x_stern_vert (-) 


* ( (AUV bow vertical * fabs (AUV bow vertical) * x bow vertical) 
*(AUV stern vertical * fabs (AUV stern vertical) * x stern vertical)); 


// EPSILON terms have been removed due to revised equations of motion 
// + xho2 * 14 * M qn * U*Q * EPSILON 

// * rho2 * L3 * (M wn * U*W * M dsn * U*fabs(U) * delta planes. stern) 
/ / * EPSILON; 


ΜΗ η... οι r 
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if (TRACE || TRACE_EOM || (rhs [PITCH] >= MAX_PITCH)) // Pitch TRACE 

{ 

Pee ΞΕ termis*oeco- 0 Ix - I2) *—P*R + Ixy * O*R - I yz * P*Q 
- I_xz * (P2 - R2) << endl; 


cout << Ç"term2=" << + m * ( x_G * ( -U*Q + V*P) - z_G * ( — V*R + W*Q)) 
«« endl; 
ο. << “term3=" << + rho2 * LS * ( Мм рр * P2 + M_pr * P*R +M rr 
* R*fabs (R) 
πμ πα ee 
UNE S FO abs (0)) // hovering pitch drag 


«« endl; 


ENNES--o'termd-" << + rho2 * Ld * ( M uq * U*QO + Mvp * V*P + M vr * V*R) 
<< endl; 


G Fi "tCermS=]" << - rho2 * L3. * (M uw * U*W + M_vv * V2 
+ U*fabs(U) * ( M uu delta. bow * delta planes. bow 
* M uu delta stern * delta planes stern)) 


«« endl; 


СЕШЕ << "“term6=" << + pitch_integral << " pitch_integral" 


<< endl; 
cout << "term7=" << - (x_G * Weight - revised x B * revisedBuoyancy) 
* COSTHETA * COSPHI 
«« endl; 
cout << "term8=" << - (z_G * Weight - z B * revisedBuoyancy) * sinTHETA 
«« endl; 
cout << "term9=" << + (Σο δα ο - τα ο) 
// each thruster 2.0 lb per 24V signal squared 
// multiplied by respective moment arms 
// x_bow_vertical (+), x_stern_vert (-) 
* ( (AUV bow vertical * fabs (AUV bow vertical) * x bow vertical) 
-(AUV stern vertical * fabs (AUV stern vertical) * x stern vertical)) 
«« endl; 
cout «« "termlO,termllz" «« "EPSILON terms, no longer used" 
«« endl; 


// Cout << "terml0=" << + rho2 * L4 * M. qn * U*Q * EPSILON 
/ / << епа1; 


Ἱ ουιες << "termll=" << + rho2 * L3 * (M wn * U*W - M dsn * U*£abs (U) 
m * delta planes, stern) 
Zl * EPSILON 
// << endl; 
BE 77/77/70 7/77/77/7//2/77/7////7//77///////7/177////////////7////7/////77/7/7/1 
rhs [YAW ] = // Yaw Motion Equation right hand side -------------------- "ird 
БИРЕУ ЕО) РО t I xy * (P2. .- Q2) + I vz * P*R - I.xz * Q*R 
Seite i XG == ( U*R = W*P) = ος * ( —- V*R + W*Q)) 
τισ БО N pa * POTEN gr * O'R 


+ Nr *R 
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+ N_rr * R * fabs (R)) // hovering yaw drag 
+ rho2 * L4 ο ΠΠ υ + N ur ,νηα η 
* Nowp * W*P + N_ wr ~ WTR) 


* rho2 * L3w* (mv * U*V - N vw 


+ 


U*fabs(U) * N uu delta rb * delta, rudder. bow 
U*fabs(U) * N, uu delta, rs * delta, rudder stern) 


- yaw integral 
* (x G * Weight - revised x B * revisedBuoyancy) * cosTHETA * sinPHI 
+ (у Сс * Weight - y B * revisedBuoyancy) * sinTHETA 
- (2.0 / (24.0 * 24.0)) // each thruster 2.0 lb per 24V signal squared 
// multiplied by respective moment arrms 
* ( (AUV bow lateral * fabs (AUV. bow lateral) * x bow lateral ) 
-X(AUV stern lateral * fabs (AUV stern lateral) * x stern, lateral )) 
ΓΕ τς τς οὐ 
* ( square (SPEED PER, RPM) * 0.5 // propeller yaw 


* (  AUV port rpm * fabs(AUV port rpm) * y port propeller 
* port propeller. efficiency 


* AUV stbd rpm * fabs(AUV stbd rpm) * y stbd propeller 
* stbd propeller efficiency) 


// *** revision: removed ( - U * fabs(U) ) term from dissertation, incorrect 
/ / - U * fabs(U)); 
И; 


“///////////7//////7///70 0 h ο ο ο ο ο ο ο ο. ο. ο ο ο ο ο ο ου ο ο ο ,,,; 


if (TRACE || TRACE EOM || (rhs [YAW] »- MAX YAW)) // Yaw TRACE 
{ 
cout << "* yaw terml=" << - (I_y - I_x) * P*Q + I_xy * (P2 - Q2) 
ΞΖ TPR = I xZ = O'R 
<< endl; 
cout << “termZ=* << - ш * ( XG * ( U*R — W*P) = УС * ( - V*R + W*Q)) 
<< endl; 


cout «« "term3-" «« + rno? ALCS Npa ~ PO амат ох 
® МЕСЕ 
+ М гург * К * fabs (R)) // hovering yaw drag 
<< endl; 


Soule.) “Cerma4=" << + rho2 * τὰ τι} 0 Pt Nur * U*R + INE YG s V QO 


ΕΝ * W*P + N_wr * W*R) 
<< endl; 


cout << "term5=" << + rho2 * L3 * (N uv * U*V + N_vw * V*W 


+ U*fabs(U) * N_uu_delta_rb * delta_rudder_bow 
- U*fabs(U) * N_uu_delta_rs * delta_rudder_stern) 
<< endl; 


cout << "term6=" << - yaw_integral << " yaw_integral" 


-120- 


«« endl; 


cout << "term7=" << + (x_G * Weight - revised x B * revisedBuoyancy) 
* cosTHETA * sinPHI 
<< endl; 
cout << "term8=" << + (y_G * Weight - y B * revisedBuoyancy) * sinTHETA 
<< endl; 
КОШЕ << *term9-" «« - (2.0 / (24.0 * 24.0)) 


// each thruster 2.0 lb per 24V signal squared 
// multiplied by respective moment arms 
* ( (AUV bow lateral * fabs (AUV bow lateral) * x bow lateral ) 
*(AUV stern, lateral * fabs (AUV stern lateral) * x stern lateral )) 


«« endl; 


КОП << "Сегт10б=<" «« - rho2 * L2 * C dO 


* ( square (SPEED PER RPM) 


* 0.5 // propeller yaw 


* (  AUV port rpm * fabs(AUV port rpm) * y port propeller 
* port propeller efficiency 


- AUV stbd rpm * fabs(AUV stbd rpm) * y stbd propeller 


κ 


stbd propeller efficiency) 


// *** yevision: removed ( - U * fabs(U) ) term from dissertation, incorrect 


ο . - U * fabs(U)); 


«« endl; 


) 


ОО, 


// debug section. selectively set rhs values to zero to isolate problems. 
/ / also see zeroing of sway/heave/pitch/yaw integrals. 


// rhs [SURGE] 
// rhs [SWAY ] 
// rhs [HEAVE] 
7// ths [ROLL ] 
// rhs [PITCH] 
// rhs [YAW $j 


а 
, 
, 
; 
; 


. 
t 


u n ww m H H 


οοσοσσσ 
оооооо 


* 
, 


MAX ACCELERATIONS EXCEEDED - 
((rhs [SURGE] »- MAX SURGE) 


| (rhs [SWAY ] >= MAX SWAY ) 


| || 
(rhs [HEAVE] »- MAX HEAVE) || (rhs [ROLL ] >= MAX ROLL ) || 
| 


(rhs [PITCH] »- MAX PITCH) 

if (TRACE) 

( 
cout «« " SURGE = "<< SURGE 
cout << " SWAY ЕС SWAY 
COUCE << " HEAVE = " << HEAVE 
cout << " ROLL = "< ROLL 
pout << " PITCH = "<< PITCH 
Eout «« " YAW = " << YAW 

) 

1f (TRACE || TRACE_EOM) 

( 
cout << " SURGE = " << SURGE 
Sout << " SWAY — ed SWAY 
cout «« " HEAVE = " << HEAVE 
Cout << " ROLL ZM << ROLL 


<< 
<< 
<< 


| (rhs [YAW ] >= MAX YAW )) 


endl; 
endl; 
endl; 
endl; 
endl; 
endl; 


endl; 
endl; 
endl; 
endl; 
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у 


if 


) 


courbe PITCH = ii< PITCH << endl; 


cout «ec a YAW = " << YAW << endl; 

cout << "rhs [SURGE] = " << rhs [SURGE] << endl; 

cout << "rhs [SWAY |= -- ths [SWAY ] << endl: 

cout << "rhs [HEAVE) = " << rhs [HEAVE] << endl; 

cout << “rhs [ROLL ] = " << rhs [ROLL ] << endl; 

Cout <<)" rnse (PITGH) =) =< rhs [PITCH] -- πα. 

cout << "rhs [YAW  ' ] = w << rhs [YAW ] << endl; 

cout << "mass_inverse: a print matrix6x6 (mass inverse); 

(TRACE | | TRACE_EOM | | MAX ACCELERATIONS. EXCEEDED) 

COUL. <<)" velocities: <" << U << m ο τς сс” тсе ү с=с. 
<< P << "<< O << D κ ο Ыл Кес Кетүү 

Cout << "RHS: 1g print_matrix6 (rhs); 


κ λε. ο ο ου ο. ο ου ου Л 


// calculate new accelerations matrix using mass, inverse & rhs, print ----- TZ 


multiply6x6 6 (mass inverse, rhs, new acceleration); 


if (TRACE || TRACE EOM) 
( 
cout << "Accelerations:  "; print matrix6 (new acceleration); 
) 
// limit accelerations ---------------------------------------------------- 75 


if (CLAMP) // values are for NPS AUV, consider parameterizing 
( 


clamp (& new acceleration [SURGE], -MAX SURGE, MAX SURGE, 
"new acceleration [SURGE]"); 
clamp (& new acceleration [SWAY ], -MAX SWAY , MAX SWAY , 


"new acceleration [SWAY 13"); 
clamp (& new acceleration [HEAVE], -MAX HEAVE, MAX HEAVE, 
"new acceleration [HEAVE]"); 


clamp (& new acceleration [ROLD ], -MAX ROLL , MAX ROLL , 
"new acceleration [ROLLD ]"); 

clamp (& new acceleration [PITCH], -MAX PITCH, MAX PITCH, 
"new acceleration [PITCH]"); 

clamp (& new acceleration [YAW ], -MAX YAW , МАХ YAW , 
"new acceleration [YAW ]"); 


// find velocities by integrating averaged accelerations ----------------- 1 
í (Heun integration) 

new_velocity [SURGE] = 0.5 * (u dot + new_acceleration [SURGE]) * dt + U; 
new_velocity [SWAY ] = 0.5 * (v_dot + new_acceleration [SWAY ]) * dt + V; 
new_velocity [HEAVE] = 0.5 * (w_dot + new_acceleration [HEAVE]) * dt + W; 
new_velocity [ROLL ] = 0.5 * (p_dot + new_acceleration [ROLL ]) * dt + P; 
new_velocity [PITCH] = 0.5 * (q dot + new_acceleration [PITCH]) * dt + Q; 
new velocity [YAW ] 0.5 * (τ dot 1: new acceleration [YAW ]) * dt + R; 
// find velocities by integrating instantaneous accelerations 

70 (Euler integration) 

/ / (this method is less accurate and is not used, although at small 


/ / timesteps the difference is negligible) 
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// new velocity [SURGE] » (new acceleration (SURGE]) * dt + U; 

// new velocity [SWAY ] = (new acceleration (SWAY ]) * dt + V; 

// new velocity [HEAVE] - (new acceleration [HEAVE]) * dt + W; 

// new velocity (ROLL ] » (new acceleration (ROLL ]) * dt + P; 

// new velocity [PITCH] - (new acceleration (PITCH]) * dt + Q; 

// new velocity [ΥΠ ] = (new acceleration [YAW ]) * dt + R; 

// Note that surge velocity may be negative under model constraints 

// but reverse stability is a problem. Originally clamped non-negative. 


1 £ 
( 
clamp (& пем velocity [SURGE], -MAX SURGE, MAX SURGE, 
"new velocity (SURGE] velocity"); 


(CLAMP) 


) 


// update UUVBody state accelerations to newly-calculated values -------- {7 
u_dot = new_acceleration [SURGE]; 
v dot = new_acceleration [SWAY ]; 
w dot - new acceleration (HEAVE]; 
p.dot - new acceleration [ROLL ]; 
q dot - new acceleration [PITCH]; 
r dot - new acceleration [YAW 1; 
// calculate world coordinate system linear & angular velocities -------- a 


// see Cooke Figure 10 for corrections to Healey equations for x/y/z_dot: 
// also Healey course notes eqn (26) and Frank-McGhee corrected paper (A.8) 
x_dot = AUV_oceancurrent_x 
ο COS (PSI) * cos (THETA) 
+ V * (cos (PSI) * sin (THETA) * sin (PHI) - sin (PSI) * cos(PHI)) 
+ W * (cos (PSI) * sin (THETA) * cos (PHI) + sin (PSI) * sin(PHI)); 
y_dot = AUV_oceancurrent_y 
+ U * Sin (PSI) * cos (THETA) 
+ V * (sin (PSI) * sin (THETA) * sin (PHI) + cos (PSI) * cos(PHI)) 
+ W * (Sin (PSI) * Sin (THETA) * cos (PHI) - cos (PSI) * sin(PHI)); 
z_dot = AUV_oceancurrent_z 
RU * sin (TRETA) 
+ V * cos (THETA) * sin (PHI) 
+ W “ COS (THETA) * cos (PHI); 
ne dot = P + Q * sin (PHI) * tan (THETA) 
Ρα -ο (PHI) * tan (THETA); 
theta_dot = Q * cos (PHI) 
- R * sin (PHI); 
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if (cos (THETA) == 020) 

{ 
cout << "UUVBody::integrate_equations_of_motion (): " << endl; 
οσους κο ᾗὉ cos (THETA) -- 0.0 so psi dot set equal to zero." «« endl; 
psi dot = 00: 

) 

else psi dot 


(Q* sin (PHI) + R * cos (PHI)) / cos (THETA); 


Vector3D linear rates -  Vector3D (x dot, y dot, z dot); 
if (TRACE || TRACE EOM) 
( 

cout «« endl; 

coute x --cdot, y dot, z dot» 


" «« linear rates «« endl; 


Cout << " magnitude = " «« linear rates.magnitude () 
<< endl; 
} 
Vector3D euler_rates = Vector3D (phi_dot, theta_dot, psi_dot); 
if (TRACE || TRACE_EOM) 
{ 
cout << "<phi_dot, theta_dot, psi_dot> = " << euler_rates << endl; 
cout << " magnitude = " << euler_rates.magnitude () 
<< endl; 
} 
// calculate world coordinate system homogenous transform matrix -------- 2 
Hmatrix Hincremental - Hmatrix (); // default initialization 
Hincremental.set orientation ( P * dt, Q * dt, R * dt ); 
Hincremental.rotate ( PHI, THETA, PSI )5 


double omega x Hincremental.phi value (95 
double omega y Hincremental.theta value (); 
double omega z - Hincremental.psi value (je 


il 


Vector3D world rates -  Vector3D (omega x, omega y, omega, Z); 

if (TRACE || TRACE EOM) 

( 
cout «« "«omega x, omega y, omega z» = " «« world rates «« endl; 
cout << " magnitude = " «« world rates.magnitude () 

<< endl; 

} 

Hmatrix Hrevisedl1 = Hmatrix (); // default initialization 

Hrevisedl.incremental, rotation ( phi dot, theta dot, psi. dot, dt ); 


Hrevisedl.incremental translation ( U, V, W, dt ); 

Hmatrix Hproductl = Hprevious * Hrevised1; 

Hproductl.incremental_translation (AUV_oceancurrent_x, 
AUV_oceancurrent_y, 
AUV_oceancurrent_z, dt); 


Hprevious - Hproducti; 


// translate and rotate and update time in RigidBody state ---------------- Ji 
// note world coordinate system is used by RigidBody: 


set angular, velocities (phi dot, theta dot, psi. dot); 


set linear velocities ( x dot, v dot, Z dot); 
set_time_of_posture (current_uuv_time); 
update Hmatrix (аг); 
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ΤΕ 
( 


) 


(TRACE) 


cout << 


"incremental hmatrix 


Hincremental.print_hmatrix (); 


cout << 


*revisedl hmatrix = 


Hrevisedl.print hmatrix (); 


cout «« 


"productl hmatrix 


-— 
-- 


Hproductl.print hmatrix (); 


Cout << 


"original hmatrix 


hmartrix.prirnt hmarrix" (); 


— — — — — — — — — — — — — — — — — — — — — € I ——  — — — — — — — — —  —  —  — — — — — — — — — — — — — —  — —  — — ο ο...  — «ο. ος ος ος ος ος ος ος ος ος 


1f (TRACE) cout 
hmatrix - Hprodu 
/ / 


«« 
ie: 


"substituting productl hmatrix" << endl; 


// Save body-coordinate-system velocities for the next loop: 


U = new_velocity [SURGE]; 

V - new velocity [SWAY ]; 

W - new velocity [HEAVE] ; 

Р = new velocity [ROLL ]; 

О = пем velocity [PITCH]; 

R = new velocity [YAW 1; 
EU << world U =" << U << 
@ouce<< “world V =" << V << 
cout << "world W =" << W << 
EM «c "world P z" «« P << 
cout «« "world Q z" «« Q «« 
rout << "world R =" << R << 
LI 


// update all hydrodynamics-model-provided state variables in AUV_globals.h 


ccc cr - — a  —  — —  — —  — — — —  — — —  — — —  — — — — — — — —  — — ως... — — 


κ. σος " << x dot << end1; 
Veaoc =" << y dot << endl; 
Eclo E 3 U aa a Ot << endl; 
phi_dot οι Phi dort << endl; 
theta dot = " << theta_dot << endl; 
psi_dot =" ες Dsi dot << end1; 


v prior to retransmittal to AUV via AUVsocket 

AUV_time = current_uuv_time; // mission time 

AUV_x = x_value ОЕ «αν < position in world coordinates 
AUV y - y value (yr position in world coordinates 
AUV z - Z value ΠΕ position in world coordinates 
AUV phi - phi, value (); // roll posture in world coordinates 
AUV theta - theta value (); // pitch posture in world coordinates 
AUV psi - psi, value (y; 77 -vaw posture in world coordinates 
AUV speed-new velocity [SURGE]; // paddlewheel speed = u = surge 

AUV_u - new velocity [SURGE]; // surge linear velocity along x-axis 
AUV_v - new velocity [SWAY ]; // sway linear velocity along y-axis 
AUV_w = new_velocity [HEAVE]; // heave linear velocity along x-axis 
AUV_p = new_velocity [ROLL ]; // roll angular velocity about x-axis 
AUV q - new velocity [PITCH]; // pitch angular velocity about y-axis 
AUV r - new velocity [YAW ]; // yaw angular velocity about z-axis 
AUV u. dot = u_dot; АА linear acceleration along x-axis 
AUV v dot = νι σε, МА linear acceleration along y-axis 
AUV w dot zw dot; / / linear acceleration along x-axis 
AUV p dot z p dot; / / angular acceleration about x-axis 
AUV q dot = d dot; 77 angular acceleration about y-axis 
AUV r dot zug dot АА angular acceleration about z-axis 
AUV x dot - x dot; Ta Euler velocity along North-axis 
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AUV y dot sy οσς 

AUV z dot 2 2 dots 
AUV phi dot = рї ао: 
AUV theta dot - theta dot; 
AUV psi. dot 2 psi*dot: 


τ Euler velocity 
Ju Euler velocity 
// Euler rotation rate 
// Euler rotation rate 
// Euler rotation rate 


along 
along 
about 
about 
about 


divetracker rangel = sqrt (sqr (AUV x - DiveTrackerl x) + 
βατ (AUV y - DiveTrackerl y) + 
sqr (AUV Z - DiveTrackerl.2)); 


divetracker_range2 = sqrt (sqr (AUV x - DiveTracker2 x) + 
sqr (AUV y - DiveTracker2 y) - 
sqr (AUV_z - DiveTracker2_z)); 


στο -—-----o n 
//set value of doppler sonar outputs 
//----------------------------------- 
//doppler speed over ground in meters/sec 


doppler. sog. u = 


U = 0,3048; 


doppler οσον εν * 0.3048; 


/ / doppler 


doppler_stw_u = 


speed through water in meters/sec 


doppler_stw_u * 


doppler_stw_v = doppler_stw_v * 


0.3048; 
0.3048; 


East-axis 
Depth-axis 
North-axis 

East-axis 
Depth-axis 


//doppler altitude returns height of AUV above bottom in meters, I assume total depth of 


100 meters 


doppler altitude = 100.0 


- AUV 2; 


if (FALSE && TRACE EOM && MAX ACCELERATIONS EXCEEDED) 


( 
char 
cout 
cin 
cout 


) 


return; 


user_pause; 


<< "'"zzzz Hitoenter toseconbtaihue ----τ; 


»» user. pause; 
«« endl; 


// integrate equations of motion () complete 
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APPENDIX B. VIRTUAL ENVIRONMENT JAVA/VRML CODE 


1. Java Source Code 


This appendix includes the files needed for the Phoenix AUV dynamics to run in Java with the 


virtual environment done in VRML. Since the functionality of the C++ and Java version are the same 


the actual source code is not included. The source code is freely distributed at 


http://www.stl.nps.navy.mil/-auv. Please feel free to download a complete version of the code if it is 


required. The complete list of Java files needed to run the virtual environment follows: 


dynamics.java 
AUVglobals.java 
SonarModel.java 
AUVmodel.java 
RigidBody.java 
Hmatrix.java 


MathU java 


UUVBody.java 
UUVmodel.java 
AUVsocket.java 
FlowFileReader.java 
DISNetworkedRigidBody.java 
Vector3D.java 


Console.java 


Additionally, the DIS-Java-VRML library is required to compile the program. This can be 


obtained free of charge at http://www.stl.nps.navy.mil/dis-java-vrml. 
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2 AUV virtual.wrl 


#VRML V2.0 utf8 

#This file creates a Virtual world for the Phoenix AUV 
#Author: Kevin Byrne 

#Date : 28 January 1998 

+H H HH FH Ht HH FH FE HE OH FH HF OH HF HH HOHE OH EF EE OH HF HEE HE HH 

#This is the externproto to link in DIS pdu's 


EXTERNPROTO EspduReadTransformTrace [ 


field SFString marking # 0..11 character label for 
entity 

field SFTime readInterval # seconds between DIS updates 
field SFString address # multicast address or 
"unicast" 

field SFInt32 port # port number 
exposedField MFNode children 

field SFVec3f translation 

field SFRotation rotation 

exposedField SFVec3f scale 

exposedField SFRotation scaleOrientation 

field SFVec3f bboxCenter 

field SFVec3f bboxSize 

exposedField SFVec3f center 

eventIn MFNode addChildren 

eventIn MFNode removeChildren 

] [ "EspduReadTransform.wrl" 


"../JavaViaScriptNode/EspduReadTransform.wrl" # local or remote URLs for the 
EXTERNPROTO 


"http://www.stl.nps.navy.mil/dis-java-vrml/mil/navy/nps/JavaViaScriptNode/EspduReadTransfo 
rm wri^ 
] 
EspduReadTransformTrace ( 
marking "Phoenix AUV" 


readInterval 2 # seconds between DIS reads 


# do not modify address/port while using unicast-only browser, run bridge instead 


# address “224 2.244. 14]" # NPS AUV exercise default, 
multicast 
# port 3111 # NPS AUV exercise default 


children Inline ( 
url [ "phoenix auv.wrl" 
"http://web.nps.navy.mil/-kmbyrne/AUVvw/phoenix auv.wrl" 
) 


translation 2 -2 O0 # offset for initial location/orientacion, 


#End of Proto 
HH Ht H HOH HH HH FH HOH FH EE FH HH HF HE OH SE OH SE HE OH OE OFF OH FH HF OH OE HH OF OH FF FF 
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Group ( 
children [ 
#This Section states Navigation info 
NavigationInfo ( 


type "EXAMINE" #In the end should be FLY 
speed 10.0 
avatarSize ο ο 1.6, 0:75] 


}, 
#This section adds a background to the scene 
Background ( 


skyColor [ 

0:50:70 32 10 75 

5 ο ο ον ο 

ο ο ο ιο Ἡ 
skvaAngle 1 σου, 1.571] 


}, 


#This Section creates the Ocean Floor 
Transform { 
translation -75.0 -30.0 -75.0 
children Shape ( 
appearance Appearance ( 
material Material ( 
ambientIntensity 0.50 
dilfüuseColor 0.3 0.11 0:00 
specularColor 0.75 0.33 0.00 
shininess 0.10 
) 
) 
geometry ElevationGrid ( 
xDimension 15 
zDimension 15 
xSpacing 10 
zSpacing 10 


solid FALSE 
creaseAngle 0.785 

height [0.0 0.0 0.0 0.0 0.0 0.0 0.0 
0208070 0.070. 0 0.0 0:0070 
0.070: 0 0.070070. 0 0070.0 
ο ο ο ο, ου ο ο ο» ο ο ο 0.0 
Ὁ ο ο οσο ο οσο σου 
ο ο ο ο 02.0 ο ο ο ο ο 0 
оо ооо оо; о 0.0 0.0 00 
0:0 0.0 0.0.0.0 0.0-0.0 0.0 
ο ος ο ο ο ο ο ο ο 0. 0.0 
ο ος ο, Ότο ος ο ο ο ο.5 
ου οσο ου ο ο ο ο ο Ὁ 
0.0 0.0 007070 0.0 001070 
0.0 0.00.0 0.0 0.0 0.0 0.0 
0.00 0105020 "020 070 070 0 
ο ο ὐυ 001070 0 0 0 0 07050 


со (а>) (ер) (ар) (ар) (ер) (ар) о (ар) Сер) (ер) со осоо о 


) 
Ji 


#This section adds the sea surface 

#It uses an indexed face set 

Shape ( 

appearance Appearance ( 
material Material ( 

ambientIntensity 0.70 
diffuseColor 0.0 0.0 170 
specularColor 0.0 0.0 1.00 
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shininess 0.10 
transparency 0.3 
) 
) 
geometry IndexedFaceSet { 
coord Coordinate ( 
point [| -75 0 52 


=) 5 ο ο” 
J5 ο Se 
758 оо е 


) 
roordlIndex [| 0, 1. 29553 2 
solid FALSE 


), 


#This section adds the Sun 
DirectionalLight { 
direction 0.0 -1.0 0.0 

|. 


#This Section places a 688 Class Submarine in the scene 
Transform { 
translation 0.0 -5.0 40.0 
rotation 0.0 1.0 0.0 зе“ 
#This sub must be scaled down from 600 M to -100 M 
scale 0.1666 0.1666 0.1666 
children [ 
Inline { 
bboxSize 500.0 300.0 300.0 | 
οτι “6ss wells 


] 
2s 


#This transform places the oil rig in the scene 
Transform ( 
translation -45.0 7.0 -10.0 
children [ 
Inline ( 
bboxSize 200.0 200.0 200.0 
Url нт] го УЕЛ 
) 
] 


), 


#This places a tube on the sea floor 
Transform { 
translation 0.0 -30.0 0.0 
rotation тоо орот 
children [ 
Shape ( 
appearance Appearance ( 
materlal Material ( 
diffuseColor 0.8 1.0 0.0 


Sm 


) 

) 

geometry Cylinder ( 
height 6.0 
top FALSE 


bottom FALSE 
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of file AUVvirtual.wrl 
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3. Oil rig.wrl 
#VRML V2.0 utf8 


This file creates an oil rig for the Phoenix AUV VW 
#Author: Kevin Byrne 
#Date : 28 January 1998 


NavigationInfo { 
type [ "EXAMINE" "ALL" ] 


) 


Viewpoint { 
position 17 35 0 
orientation 0 10 0 
description “On Oil Rig” 
) 


Group { 
children [ 


#This creates the left forward leg 
Transform { 
translation 0.0 -10.0 0.0 
children | 
Shape { 
appearance Appearance { 
Material DEF blueMetal Material { 
diffuseColor 0.4 0.4 1.0 
) 
) 


geometry DEF Leg Cylinder { 
radius 3.0 
height 55.0 


), 


#Back Left Leg 
Transform { 
translation 0.0 -10.0 -35.0 
children [ 
Shape { 
appearance Appearance { 
material USE blueMetal 

) 


geometry USE Leg 


), 


#Back Right Leg 
Transform ( 
translation 35.0 -10.0 -35.0 
children [ 
Shape ( 
appearance Appearance ( 
material USE blueMetal 

) 
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geometry USE Leg 


), 


#Front Right Leg 
Transform ( 
translation 35.0 -10.0 0.0 
children [ 
Shape ( 
appearance Appearance ( 
material USE blueMetal 

) 


geometry USE Leg 


), 


#This creates the left forward crossbeam 
Transform { 

translation 17.5 10.0 0.0 

rotation ο ο ο οἱ ὁ 1. 
children | 
Shape { 

appearance Appearance { 
Material DEF white Material { 
daffusecolor 1.0 1.0 1.0 


А 


) 
) 


geometry DEF CrossLeg Cylinder ( 
radius 0.8 
height 38.0 


), 


#Left forward cross beam 2 
Transform { 
translacion 17.5 10.0 0.0 
0 


rotation OF Or ο. -1.2 
children [ 
Shape { 


appearance Appearance { 
material USE white 


} 


geometry USE CrossLeg 


), 


#Left forward cross beam 3 
Transform ( 
translation 0.0 10.0 -17.5 


rotation "ο - ο ο 1.2 
children [ 
Shape ( 


appearance Appearance { 
material USE white 


) 
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geometry USE CrossLeg 


Iu 


#Left forward cross beam 4 
Transform { 
translation 0 0 10.0 -17.5 
rotation ο ο 0.0 -1.2 
children [ 
Shape ( 
appearance Appearance { 
material USE white 
) 


geometry USE CrossLeg 


1; 


#Left forward cross beam 5 
Transform ( 
translation 3520 10:0 -17.5 
rotation E 0$ 1/72 
children [ 
Shape { 
appearance Appearance { 
material USE white 


) 


geometry USE CrossLeg 


) # 


#Left forward cross beam 6 
Transform ( 
translation 35.0 10.0 -17.5 


rotation 1205050 0.0: 1-2 
children [ 
Shape ( 


appearance Appearance ( 
material USE white 


) 


geometry USE CrossLeg 


), 


#Left forward cross beam 7 
Transform { 
translation 17.5 10.0 -35.0 
rotation 070990100 9 lane 
children [ 
Shape ( 
appearance Appearance { 
material USE white 


) 


geometry USE CrossLeg 
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] 
7 
#Left forward cross beam 8 
Transform { 
πε ει. 175 10.0°—35.0 


rotation ΟΡΟ 0. $1. ο 
children [ 
Shape ( 


appearance Appearance ( 
material USE white 
) 


geometry USE CrossLeg 


), 


#This creates the bottom platform 
Transform { 
enans lation “ТУ ο τι 5 -τ.5 
children [ 
Shape { 
appearance Appearance { 
material Material { 
Gitmuseecolor 1.0 0.2 0.2 
} 
} 


geometry Box { 
size 500082050. 0 
) 


), 


#This places a simple box-like building on the oil rig 
Transform ( 
translation 27.5 22.5 -17.5 
children [ 
Shape { 
appearance Appearance ( 
material Material ( 
daffusecolor 1-0 1-0 0-0 
) 
) 


geometry Box ( 
Size 15 ϱ 8670 10.0 
) 


) 


#This places a second simple box-like building on the oil rig 
Transform { 


translation 5.0 21.5 -17.5 
children | 
Shape { 
appearance Appearance { 
Material Material { 
dirl useColor 0:4 1.0 0.4 
} 
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geometry Box ( 
size 10.0 6.0 10.0 
) 


] * end of oilRig group children 


) # end of oilRig group 


tend of file oil rig.wrl 
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4. 688.wrl 


#VRML V2.0 ut f8 

#This file creates a submarine 
#Author: Kevin Byrne 

#Date 2 Dec 1997 


#This Section builds a 688 Class Submarine 


Transform { 


children ( 
#The Submarine Hull 
Group { 

children [ 

NavigationInfo ( 
avatarSize 

rg 

Viewpoint ( 
position 
orientation 
fieldOfView 
description 

P5 

Viewpoint ( 
position 
orientation 
fieldOfView 
description 

); 

Viewpoint ( 
position 
orlentation 
fieldOfView 
description 

Js 

Viewpoint ( 
position 
orientation 
fieldOfView 
description 


), 


Viewpoint ( 
position 
orientation 
fieldOfView 
description 

p 

Viewpoint { 
position 
orientation 
fieldOfView 
description 

PE 

Viewpoint ( 
position 
orientation 
fieldOfView 
description 

ү, 

Viewpoint ( 
position 
orientation 
fieldOfView 


[ 0.3, Ἱ ο ο πο] 
-600 0 0 

ОООО 
0.8 


"Upper Foward End of 688, looking Aft" 


-40 20 -110 
0. 170908514 
0.95995 


"Upper STBD Side of 688, looking to Port" 


350 50 10 
6 1:070% Ἡ 
ОВ 


"Upper Aft End of 688, looking Fwd" 


-40 20 120 
ο ο Ὁ Ὁ 
0.95993 


"Upper Port Side of 688, looking to STBD" 


350800 MN 
0 1.070 5T 
QS 


"Lower Foward End of 688, looking Aft" 


-80 -20 -110 
0 1.0 6 2 134 
0.95993 


"Lower STBD Side of 688, looking to Port" 


350 50810 
O 1 0400515571 
0.8 


"Lower Aft End of 688, looking Fwd" 


-80 -20 120 
0 0 070 
0.952999 
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description 


1 


Transform ( 


"Lower Port Side of 688, 


looking Соб ТЕП" 


4.18889 


rotation 0.577417 -0.5773 Ου 517 
center ο αν ας 
children 
Shape { 
appearance Appearance { 
Material DEF _688 Hull Material { 
ambientIntensity 0-1 
diffuseColor 0710-299: 
specularColor ОТОГ ОЯ 
) 
) 
geometry  IndexedFaceSet ( 


coord Coordinate { 
point [ 

-162.5 4.92, 

250—165 14. 287 

-46 =175 1.43, 

=175 1.5, 

.95 -162.5 0, 

25 ασ ο.» 

„аЗ -175650 36. 

«9 = 117580 

.8 -170 10, 

15 ο το 5 10, 

18 -166 10, 

0 -166 15, 

17.8 =170 0.2; 

18 -166 O, 

18 -172.5 O, 

4.53 -160 3.29, 

Зо 29 60453 


ке ҥ > P O O O O 


> 
~J 


-0.46 -175 1.43, 
240530160930. 
-5,33 =160 173) 
2095255 165. 4 29. 
02; ΙΕ; 5, 
2423 155202257 
4 95 Ios Lr 
-2. 18. 172 5 0; 


-18.2 -170 10; 
-18.2167 510; 
τσ “τος το 
ΕΙ ο το 
=17.8 -170 0 2, 
ΠΙΕΙΣ; 
21.73 160895 337 
О 1625 -4 92 
-0.25 πο quu 
20.465175 Ὁ 5 
O =175 ` 15, 
-2.23 2 5 45) 
-1.43 -1J5 Ὁ 46; 
πλ ο 70-10» 
=18. 2 Ie a TD 
-18 σοι. 07 

0 —-T66 το 

-17 "8 ' το OD) 
=0.2 ЕТСЕ“ 
=0. 88 TEE UNUM 
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J 73 16055 33. 


0 -160 5.6, 

Ue 2a 167 7573-558 

ο τα 5 2.15, 
ο ЕБ ο 

ο ο 16091773. 

3.55 =167.5 0 281 

2" 157=172:5 0; 


18 =172 5510; 

18. 2 -r70 T9, 
ПОСЕТЕ 57110) 

О =172 6586155 
νυ ..ΠΙ5 
Πτα 15; 51; 
πο ο 170 0; 

ο 767 5915. 
ο ος =175 121; 
3 294-160 4 537 
2055585 175 512ү 
Z279 ο ο 
-1.43 -175 0.46, 
ο 167 5715; 

= л = р 


50” 

23 55 -167.570.253 

38 102507 

-1872 -170 0, 

216 ο 167 5 0; 
ΤΕ, 

αι δα πας 

-18 -172.5 10, 
=5. 6 -160107 

ο. το του ο 

ὁ Που 5767 


-D225. «167.5 -3.59% 
0 τν ο ος 

25.33 TOORE, 
-3 557 106757 00525 
0m 1/2. 5A OE 
-18.2 -170 -10, 
= “16.5 10; 

ο μυ с 

ο Σο ED 
τ: του 5 ο 
24553-16053 29€ 
Senco 1ου -ᾱ 


3 297-160 594.53, 
ο ο τι 1.21, 
π 5620788, 
1.43 -175 -0.46, 
7. 


Ὁ ο 15, 
'' ,, 5-2, 


18.2 -170 -10, 
i9 2.01675 0, 
η ο το» -θ, 
17.8 -170 -0.2, 
1739028012 -5. 33, 
Ἱ ο 5.650, 

Ἱ ου ο 0.94, 
ο ο ο 51.52, 
аага 1.1, 

2 1191739 2:91, 
3:5 917830; 
51.75, 
Jo 7 35176 5:33, 

0 1781376, 

6. 71 το 2.88, 
42.88 172 6.71, 
Jl⁄ 2 164.0; 

9706 164 6.58, 
22567107280 9, 

14 1520, 


13 3125254 35, 
4.33 152 13.31, 
0 152 14, 
ΠΟ», 
8.82 140 12.14, 
15 140 O, 
265923, 
4.85 128 14.93, 
15.7 128 0, 
12.82 116 9.32, 
4.89 116 15.07, 
15.85 116 0, 
12.94 100 9.4, 
0 100 16, 

15.22 90 4.94, 
12.94 90 9.4, 
4.94 90 15.22, 
0 90 16, 

15.22 30 4.94, 
12.94 30 9.4, 
9.4 30 12.94, 
4.94 30 15.22, 
0 30 16, 

16 30 0, 
12.94 0 9.4, 
4.94 0 15.22, 
16 0 0, 

12.94 -30 9.4, 
4.94 -30 15.2 
16 -30 0, 
12.94 -60 9.4, 
4.94 -60 15.22, 
16 -60 0, 

12.94 -80 9.4, 
4.94 -80 15.22, 
16 -80 0, 

14.93 -90 4.85, 
4.85 -90 14.93, 
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0.46 -175 -1.43, 
4.53 -160 -3.29, 
5.33 “πο 73 
0.25"=-165 >a, 


0.25 =-167°5 F 3 55, 


4.23 -165 30.25) 


3.55. «167 355-0025. 
18.2 ποτ --ἷ-. 
18 -166 -10, 

17.8 -170 -10, 

J8 1125-10, 

υ 1500, 


155221792-6 0.5, 


2.517178 


0 94 17959.0611 29, 
0517926 176, 
2.11, 
1317803. 42, 
6176707 
uoo. 
17605765 
ΠΟΘ, 
253; 
17249235 


537 


Or © OW UF 


ο το 2256; 


6.58 164 9-06, 


ο σα απ] 27 


10.65 164 3.46, 
S: 2335152011" 3355 
3.46 164 10.65, 
14.27 140 4.64, 
Jl 5323 152 8.23; 
4.64 140 14.27, 
14.93 128 4.85, 
91529512510] 217 
О 140 15, 


J5.07-116 4:59; 


16 100 


2.4 90 


12.94 
9.4 60 


2 32 116312 
0 7125802 15997 
0, 
9-4 100 12.94; 
0 116 157835; 
15.22 σοι 1T. 
12.34, 

4.94 100 τν ο. 
16 60 0, 

15.22 60 4 54; 
60 9.4, 

12.94, 

4.94 60715.22; 
ο ου το 

15.22 9 4.94, 
3.4. 0 12. ЗАЎ 

ο ο τς, 

J5.22 30 4 91 
2.4 30 Ου. 
ο ος 

15.22 -60 4.94, 
9.4 =60 12794; 
0 =60316; 

15.22 -80 4.94; 
9.4 =80 12,94, 


-82, 


0 -80 τν 

15.7 -90 0; 
529-577, 
ο ο 15 


ls -110 0; 

12. 7 ου ο ЕИ 
4.64 ιο ιτ 275 
14 -120 0, 

12.14 7552 
4.33 71200005231) 
10 ο 1 το 
11.33656 120756 25. 
461391 10165; 
ο Sos 
“50 OE 
zug ο, 

1σο ς Ὁ 

πο ο 

-71 -150 -4.88, 


OY Q) Осу СО) СО Q@ L) м ω) 


-58 -1397-9 06, 


10.65 -139 -3.46, 


== 


11.35 τος 234, 
4.64 ЛОК Та 27, 
12.14 68.82, 


4 85 =90 —14.93, 
9:23 90 12.7, 
πα ο ο 2.895, 
ο το T5 ᾳ, 
1259225 808 9-41. 
4.94 6011522, 
32.4 ου μια 9A, 
15.22 οὗ -ᾱ.ᾱ, 
0 οὐ τς 

122942 30 9.4, 
1.940605 τσ. ο, 
а о T2294, 
15.22 0 -4.94, 

0 0 -16, 
12.94.30 9.4, 
49460 52, 
9.4. 60 12-91, 
15.22 605-4794, 
090 πο 

9-4 100 -12.94, 
12.934 150 35.4, 
15.22 100 =4.94, 
ιο οὐ 07 

01100 =16, 
12582511559. 32, 
4.85 128 -14.93, 
2 ΙΕ 712 7, 
14.93 1281- 4785, 
ο 110 Е 57 

12.14 140 -8.82, 
4:33 1525 15 51, 
8.23" 1525-1153; 
13531205274. 33, 
6.58 7164F 9.06, 
10.65 164 -3.46, 
О I64"=I1.2, 
6-71 2172541 58, 
1-739125 5553, 
3.299] 26051555, 
απο το 
0 176-256; 

2 ЭТ 211. 
ο 5 το ο TS», 
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πρ Όσο 10:65; 


O о) МЮ P. Ë. O ммм ооч 


14.27 -110 43648 
8.82 -110 ΤΘ 
0 =110 155 


13.31 -120 71658 
8.23 -120 Tm EF 
O —120 τι 

9.06 -139 (Geese 
6.58 -139 ο 
11.2 -1390F 
4.88 -150 60 
0-139 11728 


6.71" 1504555; 


2.56 -150 Я 

4.88 -150 -s" m 

7.9 -150 25 

0 -139 —TI P 

9.06 -139 —6 33 

4.33 120 = я 
= ТОЕТ 5 


13.31 -120 45M 
8.82 -110 - 1 m: 
14.27 -110 -47 F 
0 ΞΕ ΙΙ 

12.7 -90 το 
4.94 -80 -1512F 
9.4 -80 -12223 
15.22 -80 29919 
0——80 16 

12.94 -60 099 
4.94 -30 -152 F 
9.4 -30 -1222F 
15.22 -30 42 Ἢ 
0 =30 165 


12:94 70529245 


4.94 30 -15 ° P 
9.4 30 -ü-12 93 
15.22 30 -4 53 
ϱ 30—16, 

12.94 60 90 
4.94 100 -15" 2 P 
4.94 90 -15:228 
9.4 90 -ü-12 215 
12.94 90 9 
15.22 90 -4 1957 
4.89 116 -15 0 p 
9.32 116 -1282F 
15.07 116 -45 35 P 
0 128 τοσα 
12.7 128 -9 B 
4.64 140 -14.27, 
8.82 140 -1ΖΡ 
14.27 140 -4.64, 
0 152 -14, 

11.33 152 ΕΙ 
.46 164 -10.657 
.06 164 -6.587 
-56 172 IF 
-88 172 -6.115 
-9 172 -2:50 
τς ορ δις 

.53 17613. 28 
.l 178 το 427 
ll 1792-2 ΝΣ 
2159-11; 
DS GE L6 


ο. ο 1.29, 
s l S 6 0.5, 
90. οι, 
33 21 
πι 21. 
605215 
90 25, 
82 24, 
us 
29, 

835 5297 

TI 26; 

607297 

90 34, 

71 34, 

86 36, 

τι 25; 

1922167 

80 24.3, 
TS Бе 
15 77726 
15 78 24.6, 
-4.94 60 15.22, 
-3 83 16, 
- l e το 
-9.4 50 172 594, 
-12.94 60 9.4, 
-15.22 60 4.94, 
-16 60 0, 
21552259054. 94, 
-12.94 60 -9.4, 
-9.4 60 -12.94, 
-4.94 60 -15.22, 
-15 77 26, 
215959 255 
556, 
ο 57 
"ο δο τα. 
SIRTI 6; 
23 7125; 
-3 82 24, 
2395815267 
-3 71 34, 
215890347 
250839297 
575, 
ο ος ον 
«1.6 179.60, 
- | 2571756 0.94; 
ο ο τν ο 1252; 
=2.91. 178: =2. 11, 
ΙΕ 2, 
-576 176 0, 
-3.29 176 -4.53, 
0-178 793.6, 
ΤΙ; --50, 
1 65 υπο 5.1, 
=7. 90172 -- 5ο, 
26.58 164 -9.06, 
-14 152 0, 
=з 1525-4 33, 
213505152 15 51, 
-14.27 140 -4.64, 
2:11:39 —15242-95.23, 
-4.64 140 -14.27, 


хо uiuo O Ç) O O Ç) Q) S GQ) GQ O O G) Q O P O 
со 
“O 


3971. 24; 
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„29179,6 -0 2947 
9 Ζ17 
δν 15. 
8316; 
TIS 
89725; 
850257 
UT σα, 
ου 
zu 

81 269 

7145205 

89 34, 

83 34, 

60 34, 

5 

75 26, 

1.25; 

75 2424.2, 
D: 5726. 
Πο 9 25, 
15 75 24.6, 
Z3 71 16; 
24.94 S0 15.22; 
29:4 90 12.94, 
212.94 90.9.4; 
- 15.22590. 2 92 
- 16 90207 
- 15.22 90 =4:94, 
=12.94 οὐ =-9.4; 
-9.4 90 -12.94, 
-4 54 SDT 15 225 
υ οὐ =16; 
2157789724 675 
Soto eae OF 
15771 255 
=9 75. 24.3, 
290981 25, 
ο 


O KO XO O O (Q) P. Q) Q) O O Ç) Q) P Q) QQ 2 PP P 
KO 
O 


2) 25, 
Z e, 
22693034: 
23971295 
2189897255 
ο πο ο) 
ο ο. 


575-15, 
ΟΙ ο τι 


E3542 ]78 - 1525 
2051195] ое 
-3.6 178 0, 
5 35 176 WP 
το πο ТБ ο. 
Ed] 
24:53 1265-3 29. 
Сао 
-9.06 164 -6.58, 
οσο πο 
-10.65 164 -3.46, 
29-230] 5251193: 
-3.46 164 -10.65, 
-12.14 140 -8.82, 
-8.82 140 -12.14, 
-15 140 0, 


-14.93 128 -4.85, -12.7 128 95285 


-9.23 7 25 1273. -4.85 128 -14I 7 
-15.7 129807 -15.07 116 25552 
-12.82 los 51 52; -9.32 116 -1 2 5 9 
-4.89 116 15.07, -15.85 ТІС 

=16 του Ὁ -12.94 10ο --- 
-9.4 100 -12.94, ϱ 116 -15.85 
-15.22 του. 1.94, -4.94 100 -ἷ»- 
-152229302-1:594) -12.94 30 -9mp 
-9.4 350 1 12.95424, -4.94 30 15 F 
=16 ο. 5 "15.220 -ᾱπ 
-12.94 0 -9.4, -9:4 0 -12.945 

-4 ο ο... τσοα ο 

-15 ο 4081.97 -12.94 -30 99 
ποια 510512 :794), -4.94 -30 -ἶἷ- 
-16 -30 0; -15.22 -60 49900 
a e O А, -9.4 -60 -122 TE 
=4.94 -60 Ἱ5 25 - 16 -60107 

"το ο 801 4.94, -12.94 -80 -Ὁ m 
-9.4 Bg 12 94. -4.94 -80 -1527F 
-16 -80 0, -15.7 -9010p 
-14.93 -90 —4.85, -9.23 -90 1 Np 
-4.85 -90 -14.93, -15 110 0, 
-14.27 -110 -4.64, -12.7 -90 -9 237 
=e 825 TOS 12 14, -4.64 -110 -14.27; 

ЕТА 120 0; -13.31 -120 -4.33, 

США 014 1002-5582, -8.23 =120 DI EP 

-4 33 Όρο ο οἱ, -10.65 =139 =з лб 

=з ОС νο. ο 55, -11.33 -120 ЗЭУ 

"ο δο. 195-506, -3.46 -139 -10.65, 
= лз 0; πο ἱρο 55 

-4.88 =150 -θ.τι, 22.560 -50ER 

28.3 = ШЕП, ο πι 1305 153350 

22:56 $150 77-9, 24.588 150867 ay 

«ο πι 1505458, -1 2.9 =150 2.56, 

=-3.46 159 10 65, -6.58 -139 9.06, 

-9.06 139 6.58, -10.65 13953 15) 

=4 33 T2013 31, -8.23 -120 11555) 
IN 125075 23, 213.31 1ο. s 

-4.64 -110 14.27, 28-82 το τ. τα 
HZ TE TES S32, -14.27 -110 4.64, 

-4:05 5 00711 93, ο: Opo 7 

=Т2 EM 23. =14.93 904 42857 

-ᾱ 51511522, -9.4 -80 12.94, 

-12.94 =80 9.4, -15.229-8004 947 

1 5 ΕΟ 5.22, -9.4 60112 πι, 

-12:94 5009.4, 215,22 260002. 929 

-4.94 -30 15.22, 290.4 =30 127-947 

212509429. 300954, -15.22 =30 4.94; 
242918081372; =-9.4 0 129945 
12.51.4, 215922. 0 4-947 

24:94. 30.15.22, -9.4 30212594. 
=12.94550 0521; -15.22 30 4.94, 

=4 ο. του 5-2, -9.4 100112: 94; 

-12.94 100 9.4, -15.22 100 4:54; 

-4.89 116 15.07, -9.32 1176212282. 

=12 582 τις TIZ, -15.07.116 4.89, 

-4.85 1257212505, =9.23 125912 7; 

2. 1230 DAS, -14.93 128 4.85; 

-4.64 140 14.27, -8.82 40812 145 

-12.14 140 8.82, -14.27 140 4.64, 

-4.33 1521 seo, =8.23 152 71155 

411.33 15243525, =13 31 1520424533; 

-3.46 164 10.65, =6.58 164 9 05; 

-9.06 164 6.58, -10.65 164 3.46, 


-142- 


λαο 5 το, -4.88 172 6.71, 
-6.71 172 4.88, πο αλ. 2.56, 
=1 ο λος 3, 3220069453. 
=-4 535 176 3.29, =5.33“ 1767-3223) 
=1 500176 3.42, -2.14217892,9]59 
-2.91 178 2.11, <3 ο 75 1232 
zo 6.1.52, -0.94 179.6 1.29, 
απ ου ο 5ο -ᾱ, 2152179. 6-095. 
1.21 -175 0.83, -1.21 -175 -0.88 ] 
creaseAngle 1.5708 
solid FALSE 
coordIndex [ 70m, lee. —1, б, 3, 1, -1, 
Ош Ал 1, 0, 5, 4, -1, 
PF60845] СБ ЛК Бк; 
Б, ОШТО, 1, 95, 11, 10, -1, 
ТОО Ol). 10, 12. 13; 1, 
ο ο ο Е 14, 15,13, στ 
Πο πο IS. -1, 153, 20, αι, -1, 
155820019. 0-1. 22, 23, 24, -1, 
С БИЛ #1, 17,026, 20, --1, 
ОКИСИ 21 ЕТ, 21,927, 19, =1; 
19. 285918, —1, 18, 29, 16, <1, 
11229091. 12,726, 25, -1, 
1105026. —1, ^ 6, 22, 4, -1, 
ДЕ ЗСЗ -1, 3, 23, 1, -1, 
ШОО 15 31, =1, 31, 32, 33, <1, 
EET LED. —1 34, 35, 36, -1, 
HE ioe ο αι, 33, 37, 40, -1, 
ZI В 2. -1, 43, 42, 44, -1, 
БИ 24372, -1, 45, 46, 47, -1, 
ДӨ, 46m 45, 7-1, 49, 50, 48, -1, 
ο) το ο  -ᾱἷ 53,252, 54, -1, 
ο 525, S ЕБ 55. 46, .-1, 
5516959, 571, 60, 59, 50, -1, 
Doe Aes oo ht OL 57,. 58, . —1, 
ο ο ου lk, 60,51, 58, —1, 
349 540561, -1, 48, 40, 48, -1, 
239, 405 48, -1, 45, 39, 46, -1, 
М, ЗӨ 45, 1, 62, 559, 47, -1, 
BE. ONE, -1, 95, 43, 6, -1, 
pr 1935,51, 63, 4L, 43. =1, 
os ge], c1. 763, 2, d. -1, 
642 2865) 9667 0-15 7642, 67, 65, 51; 
64 δρ 67, 1, 64, 69, 68, =I, 
ος το. 68, =  οο πι, το, -Ἡτ, 
62, 27572, 1, 47, 73, 72, -1, 
73 πα το =1, πο τα, 75, =1, 
74, 4975, -1, 49,261, 75, -1, 
πο 77284 78,151,779. 780, οι, = 1 
78. 8098 79,191, 82; δ3, 84, -1, 
76 «858 77.1—1,. 77529286, 80, 7-13 
Об т, =, 81-56, 753, -1; 
729. 5228 78, 1, 787950, 76. -1; 
AS. 7495 50... —1. 74, 86, 85, -1, 
73. 479 86, -1. 70, 82, 68, —L 
68, 87, 67, -1, 67, 83, 65, -1, 
23 7538 OG jut BB,289, 90, 51; 
90, 69, 64, -1, 91, 92, 93, -1, 
94. 9395, —1, 96, 94, 97, -1, 
9900/0839 99. -1. 100,99. 101, =1, 
ο δυο το -1, 102, 103. 9. =1, 
104, 103, 102, -1, 14, 29, 104, -1, 
105, 29, 28, -1, 106, 28, 107, -1, 
108, ЛОБ, 27, =1, 109, 108, 103, `=1, 


-143- 


110; 103. 111, 725 DB 1 Γι οι 
B2, 301041753 πι τος O EI е 
106, 108, 109, =1, 112, 105, 1100741. 
14,575 15: 1 πο ал ел -ᾱ- 
96,5977 104, πα Ίος. ο 1ο ЕЕ 
92990, E02, —-1, 875 96 SUE Ie 

ου, IM ecl, 92 τοῦ ο m 

113, 100, 5392, -1, 113, 55, 1ου. Ἱ. 
115, 65, 985, -1, ιο, ου ου 
114; 115, 116, πι 114, 116, ιτ ο. 
114, 117, 1183-2 114, 115, ΡΟ. 
114, 115.. 110, D APIS, 121, ΕΠΙ 
116, 122,2 11298. 1, 117, 123; 17898 
118, ТАЗ 119, T, 119,4 124 Om 
E295. 0426 121. —1. 121, ТА ТЕЕ 
122 22512531 10 —T1, 125 129 12 NE E 
124, 130725131; —1,. 126; 011532, 9129500515 
1278155 77134 5-1 1342 στο ο. 
J286 91555. 129" =1 1259, 1536, σοι = > 
1325255137, 138, -1, 138, 139, 133, -ι 
τ 1407, 1359, =1, 135. 140 1219 1 
141. 1425156 7 1, 137 143 1242206555 17 
144, 145 9139. το 19, 116. ΠΠ; 
140, 147, 148, -1, 148, 1497 142 ΙΙ, 
143.0150; 145, ~1, 145; ISPI 2A 1; 
1527 1553, 146, -1, 146, 1532 5 14 ri 
T47 σοι 149, —1, 155, T5520 0 Se 
J50 157 5151, =, 151, ТЫБ Сз = 
153, 158, 154, -1, 154, 159571607517 
Jol 271652 7156, =1, 156, 1631651572 κι 
ЕРТС 7158, —1,'158, 164, ποσο κα. 
159,165. 166, -1, 167, 1658, 162/2515 
Jos 155’, 165, -1, 163, 170, 16i TF 
1642/2170. 5165, -1, 165, 171, 172 ΣΤ 
168, МЮ, 174, -1, 174, 175, 169, =т, 
1695220 110, —1, 170; 12927. 1 5 S 
Vio 7179 ]71, =1, 180; 151; του кет 
1921195 153, -1; 184, 165 P So p D 
TSC ο 188, -1, 188, 189 TI90 T F 
T91 ВІ τα, 181 5, los ae 
183. 3291. 7185, -1, 185,41795 X187. -ᾱἷ 
1567 Ὁ ο σος σαι, 197,9 2399 25192815 
199 199.193, -1, 195; 200, ΘΟ 2$ 1. 
19422005 195, -1; 195, 202 9019605905 
2035 6201 158, -1, 198, 205, 199 Fp 1, 
ооо ο 1, 200, 2207 020] T 1 
201,208, 202, -1, 209, 210, 204, = 
τος οτι το -1, 205, 21.2, 205, ΞΙ; 
ος ο ο ο, 157207, 214, 205 P l 
οι 16 r 2101210, 21), αν, ТЕ 
АВИ ОТО Е 212, 219, 21521 
213, О2О 214, -1, 216, 221, 217, 951-5 
2171892252223. πι, 223, 224; 218,1. 
ІВ 25M O9. 7-1, 219, 226, 410, 15 
22] 420» 225 —1, 222, 228,229, 1» 
229 8 O02247 -1, 224, 231, 225, τη 
7,226, -1, 207), 233, 228, =L 
228 τα ο 5-1, 235, 236, 200, τ; 
230 D l l 231, 2371094292 5$ 15 
ο. Ἡ., -1, 233, 23952923541, 2915 
2301 102210502536, -1, 236, 2421; 237,81, 
290] 280051242, —1, 243, 10, 72390215 
2397128502442, —-1, 244, 33. 24000 * 1. 
2410 0E? 11,1. αι, 241, 0, 245, -1, 
240909 ο 1, 248, 113 5091» €] 


-144- 


ο ЭА 1, 250, 24975 96, ει, 

ο ου 5 1, 251, 252.246, 5], 

2o τοσα, —1, 254, 248, 249, -1, 
2595225512 250, σαι, 238, 250, 243, <1, 
ОООО К 5]o-l, 258, 256, 253, -1, 
ОБОО 22515 -1, 260, 254, 255, -1, 
ου  ο5ρ5 2ο τι, 261, 257, 256, -1, 
ἔπ... 259 5-1, 7263, 258, 259, -1, 
ОЕТ 2260, 5—15 221, 264, 227, -1, 
DEB ου е Е 26], 261, 262, -1, 
ОС ШОС АСС 269 268; 264, -1, 
Δ ΔΛπ------:-]. ΞΖιυς,. 271, 265, -1, 
,͵,--᾿᾿“᾿Ξ᾿᾿᾿ΞΞ.ι..-τ., 267, 268, -1, 
πο τὸ οὗ -—]1, 7215, 274, 216, -1, 
πι C 02201,2271, 270, 272, —1, 
πο. πο ον πι 279 42135, 2914, -1, 
ΙΗ, 215, 21, 2804. (281, 275, -1, 
ο Oca 1582835 297 278, -1, 
Do Tu 2pg-—]L203, 279209, -1, 
DH g0 $2900 1.27297, 280, 5282,  —1, 
2085152921229 35 4 1,7289; 283, 284, -1, 
Jo ОЗА ον τι 290 729517 285, -1, 
ο ου ου 25,, -1; 25», 26", 2886, -1, 
ΙΕ 289, 91, 191, 289, 197, -1, 
DUERME, 290/191, 297, 290, 292, '-1, 
ο ο 2955 71, 299,> 293, 294, —1, 
ν᾽ τος τι, οσο, 302, -1, 
ο. ους 304, 306,. —1, 
O 5306508 =], 168, 3085309, -1, 
ΠΤ 500;.-1, 312, 3105, 303,1, 
ο ο οὐ 1, 314, 305, 307, -1, 
προς ο. 168, 1,515, 516, 510, -1, 
-᾽---,. τι τρ το 313 —=1, 
ο ο ου ο πα 1615: 314, 167; -1, 
ο ο 31555711322, 73207 SLT, lL, 
D OMEN T3182 7—1283247 318, 319, —1, 
ΙΤ. 1.253297 326. 3204 -ᾱ, 
CeO eo Ose, πι, οταν 322, 9323, 071, 
2 ο ὅσα. πι του 3245° 155-1, 
ο ο. ο ος c2] 299], 329, 3217 -ᾱ, 
oncle ο ο ο. ο ο. -, 
155350 4 πο 7354055555, 3350) —1, 
с ел ο ел 3337, 331,47332, -1, 
η: алт, 10 32,5338, 1372-1, 
3з dcl 3419. 3395 3361-1, 
52258530 0357, -1,.343; 7337, 3385: ^ T; 
σος ue 132, -1, 344, 345, 339,*-1, 
346, 33, 341, -1, 347, 341, 342, -1, 
ЗОВИ ЗАЗ ЕТ 125, 146, 136, -1, 
349 2950 7342. .—1;,391,. 349, 346.4 -1, 
0527346. 347, πο 1353, 347, 348,- -1, 
Τ᾽, 12ου, -]1; τα 350, 535, -1, 
IA ae. Sol, —1;21145, 551,55, —1, 
l142 12952,5399, πο ατα 353. q18..—1; 
Ju ον οσο LESS. 3957. 2354. “= 1 
358 04595908 3575. «1295360, 73614 7359,- 1, 
5.5, 66, 6}, -1, 354.7367. 7362.7 91, 
357 σου. 511. 12105987: 36508365. -1, 
ο ο 59 οσο πι ον δ σοο -ᾱ, 
359 65 ЗӨ σον 3030569 5570 — 1, 
1. θα ο ο L, 
SIZE OE 3714. πο 3735535374 στι. =], 
το. ЗБ, 374 —1, 036725375. 83:745 =), 
το ο ο 1377; 1, 3569, 378 376, Tr, 
717375, 3785 1, 374, 130, 575, -1, 


-145- 


3815 
381; 
3825 
384, 
386; 
388, 
550; 
392; 
394, 
3915 
301, 
304, 
298; 
173; 
176; 
177; 
138, 
395; 
398, 
398, 
402, 
406, 
410, 
414, 
417, 
421, 
418, 
417, 
422, 
425, 
2275 
423, 
382, 
3515 
438, 
440, 
429, 
434, 
432, 
263, 
442, 
443, 
444, 
3967 
399; 
114, 
114, 
114, 
446, 
448, 
454, 
451, 
453, 
456, 
457, 
460, 
461, 
468, 
470, 
467, 
469, 
477, 
473, 
475, 
478, 


З 
378; 
309€ 
3797 
365, 
367, 
384, 
387; 
3835 
394, 
2955 
298, 
1807 
184, 
188, 
355, 
360, 
395, 
397, 
179, 
401, 
405, 
409, 
413, 
418, 
422, 
424, 
419, 
428, 
430, 
426, 
428, 
435, 
436, 
380, 
436, 
37/5, 
439, 
439, 
440, 
430, 


431, 


432, 
3061; 
443, 
445, 
447, 
449, 
451, 
452, 
455, 
457, 
345, 
461, 
463, 
464, 
467, 
335, 
471, 
473, 
475, 
478, 
479, 
482, 
483, 


-146- 


Sub «s 
Бл le, 
ο ο -ᾱ 
Вб cT 
BOT NIIS 
D I SI 
BONN E UE 
DOS 1. 
959 E 
5ου, =i, 
392 T 
СОС 16 
DUO UE 
Ἱ τσ TS 
d EI 
556.4 1 
3535, =1; 
T90, =ї; 
395. τα, 
ο ο, 
403, — J 
407, -1, 
de 
ZI15 x15 
419, -1, 
2205 1, 
875 dq 
qo -ᾱ- 
2123, 15 
451, =I, 
do 17 
οι = 
ΙΤ 
24375 =I, 
ms rq 
439, -1, 
ООЗЕ 
3438, —1, 
A335, -1, 
441, -1, 
429, -1, 
430, -1, 
443, -1, 
dq 
5977 al; 
446, -1, 
448, -1, 
350; =1; 
447, -1, 
449, -1, 
450, -ι, 
1552, πα 
4597 E 
462, =1, 
АБЕ = 
265 T1 
463 715 
Заб =. 
εν ΓΙ, 
174, -1, 
471 1. 
472, -1, 
Eoo 1 
476, -1, 
479 61, 


381, 
382, 
389; 
385; 
357. 
389, 
ΘΠ, 
31935 
390, 
Чат 
302, 
306, 
309, 
175; 
177; 
түү, 
τοῦ, 
2957 
3987 
400, 
404, 
408, 
412, 
SOL, 
417, 
420, 
419, 
421, 
424, 
426, 
428, 
384, 
3515 
3515 
439, 
370, 
434, 
433, 
441, 
442, 
443, 
443, 
23557 
397; 
179; 
114, 
114, 
445, 
447, 
449, 
450, 
452, 
455, 
462, 
458, 
465, 
463, 
464, 
466, 
474, 
471, 
472, 
480, 
476, 
479, 


376; 
375; 
367, 
SA 
366; 
384, 
3859F 
388, 
394, 
9029 
297 
299; 
18527 
186; 
356, 
Tog: 
190, 
397, 
399, 
395; 
403, 
407, 
411, 
415, 
420, 
423, 
425, 
417; 
429, 
431, 
427, 
380, 
382: 
437, 
435, 
437, 
438, 
439, 
439, 
368; 
430, 
432, 
441, 
442, 
444, 
446, 
448, 
450, 
452, 
453, 
456, 
458, 
460, 
463, 
340, 
466, 
467, 
469, 
472, 
326] 
476, 
478, 
481, 
483, 
484, 


Sb cep. 
πλ. -1, 
neq T, 
BST 
589, =1, 
ο -Ἡᾱ 
392, =1, 
394 esL, 
S027 1. 
зл ш 
ЭОЕ 
308, -1, 
173, —1; 
Ia xp 
179; =1; 
Dg TM 
360519 
2965-15 
ΙΙ; 
TOT Sl 
405, -1, 
409, -1, 
dg MT 
416, -1, 
du Ec 
424, -1, 
426, -1, 
428, -1, 
430,. —1, 
452 F; 
434, -1, 
43535 D 
436, -1, 
3 7 2 P= l 
438, -1, 
440, -1, 
429 qu 
434, -1, 
432, 0 αι 
3012051» 
442, -1, 
431, -1, 
444, -1, 
Soo NE 
ЗЭЭЛ 
447, -1, 
449, -1, 
446, -1, 
448, -1, 
350 qM 
ПБА 
Doo, 
456, -1, 
αν m 
345 P 
461, -1, 
465, r 1 
470, =L, 
467. = 
J 55512 
477, -1, 
47577 1 
1757251 
4785 =l, 
321 Er, 


485, 
482, 
484, 
486, 
488, 
491, 
492, 
496, 
409, 
413, 
О 
498, 
500, 
502, 
504, 
511; 
506; 
510; 
5127 
514, 
5237 
5187 
520, 
528; 
524, 
526, 
528, 
559; 
5327 
534, 
S416 
537 
540, 
542, 
543, 
547, 
549, 
545, 
5525 
554, 
555; 
557; 
5317 
560, 
562, 
568; 
555, 
στο, 
565; 
570; 
5715 
3735 
5156; 
576; 
578. 
SOS 
SEI. 
506, 
584, 
586, 
395, 
403, 
407, 
588, 
590, 


486, 
488, 
489, 
492, 
493, 
408, 
412, 
301, 
498, 
500, 
202, 
504, 
291, 
508, 
στο 
512; 
514, 
281, 
518, 
320, 
522; 
524, 
2711, 
527; 
530, 
531, 
534, 
257. 
5575 
539, 
542, 
543, 
544, 
72, 

64, 

245, 
34, 

39; 

547, 
553; 
2325 
E52, 
554, 
555; 
551, 
226, 
560, 
566; 
563, 
569, 
214, 
5366, 
570, 
SL, 
= 
2027 
576, 
578, 
579, 
581, 
159; 
584, 
586, 
2196, 
402, 


-147- 


3651 τι, 481, 48587,2482 0-15 
453, —1, 483, 488, 484, -1, 
SLG T- 1, 490, 491, 7486.21 
2589 5-1, 487, 493, 488, -1. 
250-1, 7489, 311, 494. -1, 
АСВ ЖЕ 7495, 410, 492, -1, 
qq 15,5493, 414,-496, -1; 
BUE. 107, 497, 409, -ᾱ, 
ΙΙ АТЛ 499, 413, =1, 
35. 296, 416, -1, 
ο ου 50. 498, -1, 
2300581524199 5 505, 5060, -1, 
S 1555065507, 502, -1, 
Buse 152503 775509. 504, -1, 
БОЕ IUS 2856 291, -1, 
SUE Ts 5 οὐ, =L, 
noc IESUS -], 
2506 =] 5516 5517; 512, -1, 
ο ο σι ο ο 5159514; En; 
οἱ ο 1 25195 0276 251, -1,; 
ο) ον τος. 1515, -1, 
SUO MI io ο ο. =l, 
206 τι 526, 528.55, -1, 
525 5-1 9528 0529524 L, 
525 128925: 7266/72715. = 1 
527 1-1, 5ο, 5525», -1; 
Sog] og ου ο, ks 
Doo xe IE Go ο-- 1 
558. 01,558,539. 5534, =1, 
Λο ο Cok HL, 
SUCRE =] ο ο ο Scl. 
539, =1, 539, 544, 540, =1, 
2527 ea oe, oe, =[, 
БАБЕ 5546 050 doe 1, 
544, -1, 544, 64, 247, -1, 
ος πι δες δο -ᾱ- ee, 
37 0-1; 5507545 039 ЕНЕ 
62 ЭЗИ 2420054755 1; 
948, -1, 553, 548, 549, -1, 
55ου, I 5411550 0545 ЕТ, 
551. 1556 5557552 1; 
Soo л 558 5553 5542 5 15 
541 5 15559 5232572555 r= 1: 
296-1  οδἳ  οο το ο, -, 
5555 158526 ОБО аЗ τα, 
5590 1756199559; σου =I, 
ου OO 85555 562 = 1 
220901 5587 0220 5652570915 
564; 565.564, 565, -1, 
ο τι 5215707 522. £17 
267; -17 572, 567 05682-1; 
369, -17 374, 569, το. =, 
Say τι ος 208 511 -1, 
S ЕТИ 572,573, -=-1, 
57427 =1, 511,574, 516, -1, 
5755) 1.755807 575 το, =17; 
35377] "582.577 cR. =1, 
5117 1, 583.7 106 ο =1, 
ο =1 5853, 580 5561 -1, 
582; τὸ ο ο. 595 =], 
5830 -1,95401.4.5835,25812 —1, 
9855 1005 8585,55 B5 =1, 
S0T 1, 20557 179 ο =], 
400, -1, 589, 400, 402, -1, 
404, -1, 491, 404, 406, -1, 


591, 171, 587 = -:, 5.558, 5 
503, 5586, 555, -',,υ, 555 oo 05 D, 
490, 554, 151, -1; 5 166,7591, -1, 
596, 555; 592, -ᾱ r 5397 8592 5595 =, 
598, 593. 594, -1 ΠΕ, 5-1, 
595, 160, 555, T 7600 555 ole, 
601, 5396, 557, -1, ουσ зол зон к 
480; 598, 485, -1, 6037) το ο -ᾱ 
604, 603, 600, -1, 605, 600, 601, -1, 
606, 601, 602) -1 7.) 4697602, 24507, 
607, 149, 6035, =1, 505, οὐ; Του, ΛΞ; 
609; 760477605; ЕТ Ооа СОЗО ЕУ 
464, 610, 469, 1, 61, 01142, 509] 2 -Ὁτ 
612, 611, 608, -1 6B, τσ, 6007-41, 
614, =609, 610, -1, 460.601 4647, — 1S 
615, 90795. 611, πι οἱ οἱ» δις ου 
617; 612. 613, =1, 618 οι $5514, 5-1; 
255,616 А460, =  οἱο 30/691 55 215 
20, οἱ» οἷὙς, πι, ου πο ο οἱ i, 
622, 621, 618, -1, 354. 6532, 455, -ᾱ, 
СОЗ 20,619, =1 624 623 620, -1, 
625. 620, 521, -1; οσο οι ο 1 
445, 522, 454, -1, απ 1206823  -— L3 
πια, 65», 624, І 114, 6215625, =1, 
114, 625, 626, -1, 114, 626, 445, -1, 
20 E 17302-15524, 235 030/01] 

2D SIE 290425—1, 526; 17, 25 p h. 

οἱ, ο 27, =1, 193 27, 2B, 3-1 

28 ο 107-1, 25; 16, 28,581, 

Zo VM 2508 —15. 26 22, ΙΤ. τ, 
Ао О 4, 22/4524, —15 

20, μποά-1, 25, ον. ο, 545 

EL, 1$ 627, -1, 32, 31; 627 Fp h 

ο οσο, 3540525341, :26895 79 — T5 

S67 Sar 340) -1, 105 037204385 315 

23, 47 1, =1, 42; 43 41, -1, 

22, АЗ, 44, 1, 47, 46, 56, -=[, 

46, 45059; А6 ο ο -ἲ 

ο, οὗ, 6007 —1/ 5250953 051 Ls 

ο ου. οὗ. -1; ο ο δι n 

Z5, 56,007, —1, 59, 60, 58 ` 15 

25, 44, 042,.—-1, 57, 950535 215 

ο ο 77, πι αὐ, 6», Ε7,-1; 
852076, $50, —1, 586, πο ο ο, 

81, 550856, (71, 79, 56, 52, =I, 

52, 79752, τι, ο 78, 52, 1; 

BO. 74, 85, -1, 86, 74, 73, =1, 

56, 4 56; -1, 68, 82,.84, -1, 

БИ, ο 81, -1, 865, 67,87, =I, 

ο πο 25 πι 5 58, 655, —1, 

ОО ОССЕ ЭЕТ 15 

BE ο. ο. ет, Э/, 94, 95, =1; 

03, 29058-65481, 99, 2100 ,295,. -—15 

πο ο ο ο τι ο 0», T5 
ТОЗ ША И 1, 104, 29, 111, -] 
29, 10105. 242. 1,28, 106, 105, <1, 
21 ο στ 5 15105, του 27; ` 1; 
τυ ΟΝ, ΞΡ, III, 112, 1ο -, 
83, ТО ο =], 109, 105, 106, =-1, 
121, ОБ, 25 =1, 122, 116 m12 Е 
123 2087222 -1, 119, 13», 121, =1, 
120, Жл, ИИ 5-1, 121; 1565, 127, =1, 
122/92 7 NS 5-1, 128, 122, 7134, =1, 
προ, Ον... -1, 130, 71245, 129 -Ἡ, 
το, νε, ΙΙ, 133, 127; 913877 1; 
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1:357 
1367 
1397 
141, 
144, 
146, 
149, 
151; 
147, 
156, 
158, 
160, 
163, 
159; 
1627 
1702 
LUI 
175; 
1775 
151 
185, 
189, 
ο 
125, 
De 
200, 
202; 
205; 
207; 
210, 
212; 
214, 
111. 
219, 
217, 
224, 
226, 
229; 
2575 
233; 
236, 
2820 
234, 
241, 
10, 

33, 

245, 
13:35 
963 

246, 
248, 
2505 
2597 
254, 
297. 
258, 
227, 
25l, 
264, 
271, 
267, 
216; 
210, 
215, 
281; 


Γι οσο -1, 129, 1356141181; 
' 1. -1, 138, 137; 144... -1; 
ΤΙ, -1, 140, 133, 139; Ξ1, 
1:5, -1, 142, 141, 148, -1, 
s 1275. -1, 139, 145, 152, -1, 
BE 2152, 5-1, 147, 140, 146, -1, 
ESSI 2-1, 150, 143, 155, -1, 
IE 2150 5-1, 155, 152, 151, -1, 
'τ..:..1319, 154, 160, -1, 
IEEE X151  -1, 157, 150, 156, -1, 
j ο 1534, 1598, 159, -1, 
τ΄; τ 152, 16Ι, Ι6Τ, -1, 
ШЕБ ορ -1, ι54, 157, 163, -1, 
ΤΕ, τ, 150, 155, 172, -1, 
ΙΤ 1, 169, 162, 174, -1, 
ο ο τα 6550 170,178, -1, 
lS πο ο συ 309, =1, 
ioe S Ge LO 175; -1, 
ПОО το 1285 7117, =1, 
ШОО УЕЗИ ТЕВЕ —1, 
J6470183 7 —1 187; 1806, 15», -1, 
σα πο τὸ ος  1515p197, —=1, 
Πα ο πο τι ποσα. 18 5,1, 
ES 21915-18095, τοῦ 195, -1; 
к  οδο αι, 14 :9954 192, 198, —-1,; 
153 8199/7 2-1; 7201, 194, 200, -1, 
ЦБ О ОДЕ =1, 204, 203, 209, 51. 
1359/2041. 1,206, 1997205, =1, 
СОО 2067 1. 2055, 201207, —1, 
СО ο. =1; 2115, 2501, 210, -1, 
POS 2211 -]1, 21; 5ο 512, -1, 
Το τι ιο 215; 217 ια, 
DUET ο ο ЕЩЕ 20211,2255 ο, 
ΕΞ 1.220, 215, 215 η; 
ο ο τι ο ο ο 222,52 9 1. 
22092229 9] 45228 218 РАТЕ 1 
Po eG. ορ, 22] 52258 17 
225855235 151.0230, 229 235, η, 
coq ο ο. -l 232-2255 234 7 =]; 
22992238 οι οτι ο 5 -τ, 
23591234 1-177231, 2365 2327 =1, 
ο πι 4ο. οι οσο 2387 2АЗ 5*1, 
goo, 244, -1,27240 254, 244.-1, 
2367240, —1 7242 7241; 2457281, 
243, 8, =1, 244, 10, 31,--1, 
Zoe ol een), 0.824105) r, 
Ой τι αι σοι 
2218/22460 —1255915 2419 248,1, 
2409. 94, -1, 96, 243, 250, =1, 
29004247 οι "16 25 5251/5515 
54; 253, =1, 250; 254, 249, -1,; 
239,255, 1,0251, 257, 2525, 7-1; 
2b uod -ι, 25, 255, :58, -1, 
τ, νυ =1, 255,227, 260, 1, 
ZEN C765, πι, οὐ 262, 261, =1, 
СЄЗ 262, 1, 260, 205, 259, -1, 
26517260, -1, 266, 265, 271, -1, 
15. -1;25;12ε6, 257, -1, 
ου. 263, 1, 22175269, 264, =). 
О, 276, -1, 265, 272, 270, -1, 
gee, 212, -1, 269, 273, 268, -τ, 
ОШ, 269, 1, 276, 275, 281, 15 
ZEND 275,-1, 272, 2718, 277, =1, 
SED, 278, =1, 274, 209,279, -1, 
280. 286, -1, 2’, 5282, “οὐ, -ι, 
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2T 
2795 
280, 
2835 
291; 
2875 
209) 
2907 
2035 
301, 
304, 
308; 
303, 
305, 
510; 
312; 
314, 
317; 
918, 
320, 
222; 
324, 
325; 
3297 
335 
Sal; 
137; 
336; 
337; 
345, 
341, 
126: 
346, 
347, 
354, 
359, 
2:52; 
568, 
SU, 
275, 
379, 
384, 
386, 
366; 
384, 
392; 
388, 
394, 
297, 
299, 
52. 
186, 
395, 
403, 
407, 
411, 
415, 
423, 
425, 
428, 
429, 
431, 
434, 
3807 
436, 


2 
2056 
2875 
289, 
290; 
293; 
do 
297, 
299, 
300, 
3095 
68, 
31:95 
314, 
316; 
2318, 
1651, 
3205 
324, 
326, 
328, 
143, 
T, 
3902 , 
334, 
837, 
838; 
339, 
343, 
344, 
347, 
348, 
349, 
3 
179; 
358, 
255, 
899; 
862; 
370, 
371, 
ST 
SI 
387, 
389, 
385, 
оз; 
391; 
302, 
306, 
309, 
175, 
400, 
404, 
408, 
412, 
301, 
420, 
419, 
417, 
424, 
426, 
427, 
438, 
440, 
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ον 
284, -1, 
255,1. 
288; =L; 
290 15 
2. -ᾱ 
294 Е 
D93 1 
2959 XM 
а 
SOS = 16 
07 8. 1. 
300, -1; 
SIS aT 
294515 
317 15 
Sq o ME 
Ss 1 
323: -1, 
ΑΙ 
57 qu 
зог ЕЕ 
230, =l, 
е = 
5407 215 
336, =- 
E IM 
294, 517 
ΤΊ 
τ. 
346,31. 
ЗАЗ, Е 
344, -1, 
зол, = 
2579. 1 
5360, к=; 
S54, 0-1, 
Sol] 
Sod M M 
ОЭ 1 
3/4 — 
Sp s s 
Soa TEEL, 
2095 1T. 
Sedo cq 
386, -1, 
ЗВ IL 
зз, = 
295, -1, 
сэз, = 
Теа 
νι qu 
DOS MTS 
αλλ, 1; 
406, —-1, 
410, -1, 
414, -1, 
222 1] 
418, —1, 
АЕТ. 
231-1, 
2255-1, 
433, -1, 
435, -1, 
gum d, 


218, 
2867 
2920 
284, 
285, 
288, 
296, 
292. 
294, 
302, 
306, 
STIS 
30035 
168, 
312, 
"το 
зә; 
317; 
319; 
9225 
3255 
326. 
327. 
143, 
S 31. 
5325 
340, 
336; 
15ο. 
559; 
343, 
344, 
346, 
348, 
357 
361, 
364, 
2597 
JJ. 
378; 
380, 
385; 
365; 
567; 
3917 
387, 
383; 
295; 
2987 
150, 
184, 
188, 
401, 
405, 
409, 
413, 
420, 
424, 
427, 
428, 
430, 
433, 
429, 
435, 
437, 


284, 
285; 
288, 
197; 
2927 
294, 
200% 
298, 
180, 
305; 
SU 
93:05 
313; 
314, 
ET, 
13, 
321, 
3287 
155; 
925 
со 
5307 
3927 
33397 
334, 
зза, 
339; 
342, 
343, 
346, 
347, 
350, 
352; 
115; 
3567 
360; 
354, 
3/6987 
367, 
369, 
374, 
573, 
386, 
388, 
384, 
392, 
394, 
301, 
304, 
308, 
1 735 
176; 
402, 
406, 
410, 
414, 
417, 
418, 
419, 
422, 
425, 
426, 
428, 
439, 
370, 


283, = 
DOT ky, 
287,.-1, 
299g 1, 
290 x1, 
Lgs cT 
316 1, 
2 ee, 
Zoya Ls 
300, -1, 
ES Me 
494, -1, 
5127 1 
Ην cd 
πο -Ἡ 
318 T 
στο. qe 
nod dq 
324951 
5207-1; 
328, -1, 
ЭЗЕ, 
351 «13 
Sad MT 
ο ο — 1; 
937 IM 
345, -ᾱ 
Dau 
938,15 
344 -1, 
342, -1, 
459. 1 
ЗЭУ e 
ΟΙ; 
SOS MT 
190, `=1; 
Soi, 
562; F 1 
368, -1; 
Sie is 
Bo 
лке, 
364; ЕГ 
"66 1 
SOO 1 
ο, ο 
ΕΕ, -Ι 
215517 
29017 ЕЕ 
2995 qu 
πο I 
156, 1, 
400, -1, 
404, -1, 
3087921, 
ды = 
221,19 
420, -1, 
426715 
221 1 
424, -1, 
аза -ἲ, 
434, -1, 
436, -1, 
3771, —=1, 


375, 
440, 
432, 
361, 
443, 
450, 
452, 
350, 
451, 
458, 
456, 
463, 
340, 
466, 
468, 
470, 
412, 
326, 
476, 
473, 
481, 
483, 
321. 
487, 
484, 
486, 
493, 
311. 
410, 
414, 
497, 
499, 
296, 
503, 
505, 
507, 
509, 
286, 
513, 
515, 
517, 
519, 
276, 
518, 
525, 
523, 
529, 
266, 
533, 
535, 
536, 
539, 
257, 
537, 
544, 
ТОГ 

90, 

τ 
GSP 

39, 

547, 
548, 
550, 
552, 
553, 


429, 
бз, 
444, 


2396, 
399; 
445, 


447, 
453, 
456, 


452, 
460, 
462, 


458, 


465, 
467, 
469, 
466, 
474, 


471, 
478, 
480, 
476, 
484, 
481, 
488, 
491, 
487, 
489, 


495, 


493, 
407, 
411, 
415, 
497, 
499, 
506; 


503; 
505, 
507, 
509, 
516; 


Spas 
515, 
5255 


519; 
526; 
528; 


525, 
532; 
5297 
531, 
538, 


540, 


542, 
5395 
545, 
546, 
64, 
548, 
549, 
242, 
5535 
541, 
955; 
S56: 
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548, 
550; 


440, 
429, 
3657 
443, 
3597 
450, 
453, 
456, 
462, 
458, 
465, 
468, 
470, 
466, 
474, 
477, 
472, 
480, 
476, 
Bod 
481, 
484, 
490, 
487, 
494, 
495, 
496, 
406, 
410, 
414, 
497, 
499, 
506, 
508, 
905; 
507; 
509; 
5167 
515; 
515; 
517; 
519; 
523. 
528; 
525; 
533; 
5297 
532; 
538; 
535; 
5357 
540, 
545, 
546, 
247, 
=m 
2 
Ži, 


2 
551, 
549, 
242, 
556, 
558; 


E 


232085595 
556, 561, 
531,5627 
555, 5647 
562, 565, 
260, 567, 
564, 569; 
5225 1570; 
575 5a 
569. 574, 
208, 575, 
572,507, 
574, SL 
οσο, ο, 
577, 582, 
196, 583, 
580, $855, 
582, 501, 
583, 401, 
EB5 405, 
179, See, 
400, 589, 
404, 491, 
588, 591, 
589, 594, 
591, 166, 
592; 597, 
594, 485, 
296, 999, 
597, 602, 
599, 149, 
600, 605, 
602, 469, 
603, 608, 
606, 609, 
242, 6, 
S08, 515, 
464, 614, 
οι; ει», 
513, ος, 
130, 619, 
616,624) 
455, 622, 
620, 623, 
621, 626, 
colorIndex -1 
normallndex  -1 
) 
) 
) 
] 
} 
#The Propeller 
Transform { 
translation 178.5 -7.5 9.5 
rotation 0.0 0.0 0 7109571 
scale 224502 1592.89 


children [ 


DEF propeller, movement Transform ( 


rotationgb.0 02099095095 
children 
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2265 τν 
SD cc Ts 
ο I 
553, = 15 
о 
1η; -1, 
Sog M T. 
566, -1, 
ЭТЕ Е 
20301 
202 -ᾱ, 
БИБ 
Sg «cq 
Seo = iy 
358] σι, 
ο, -ᾱ, 
554, =—=1, 
586, -1, 
ο ο. νι, 
403, = 
Mq 
ΙΤ 
SS. T 
567, -i 
E Tue 
ντο, = 
526, = 
595, σα, 
ο = 
соіа 
ποσο, 1 
604, -1, 
ο. -ᾱ 
СШ cde 
εν»; -1; 
156; -1, 
STO EIE 
БОЕ 
СЕ iy 
617, -1, 
131. -1, 
620 = 
618, -1, 
619, -1, 
625, IS 


555; 
558; 
226 
5605 
526, 
563; 
566, 
214, 
568; 
570, 
571 
573; 
2025 
576, 
isi 
579, 
551, 
159, 
584, 
586. 
398, 
402, 
1717 
588, 
491, 
522; 
593; 
399; 
596; 
598; 
600, 
601, 
149, 
604, 
469, 
608, 
609; 
1:6, 
612, 
460, 
6157 
618, 
Ε1 5. 
620, 
622; 


560, 
Sok; 
563; 
565, 
566, 
5687 
5697 
571 
573 
515; 
516, 
575, 
το, 
581, 
5056; 
584, 
586, 
3955 
403, 
407, 
558, 
520, 
3917 
593; 
594; 
595; 
598; 
160; 
601, 
480, 
603, 
606, 
507; 
609, 
610, 
611, 
614, 
615; 
617; 
618. 
620; 
6217 
120, 
625; 
445, 


959, 215 
557; 1” 
220 NS 
S64, =l, 
520—157 
567; -1, 
565551, 
208 151, 
5172. 0-1; 
574, -1, 
55, =1, 
BUT -ᾱ 
Eo: = 
550 55 i 
552 I 
БЕЗЕ Е 
585, =1, 
OG ees 
401 7 T 
ДОБ 
587, =1, 
SO E TE 
Ш =l; 
5921 =1; 
590, -1, 
591 =1, 
597, -1, 
"ο =F 
οσο = 
502 = 
ο = 
SOS eras, 
1422-1 
608, -1, 
606, -1, 
507 -ἲ, 
613, -1, 
130, -1, 
OG al, 
614 -; 
619, -1, 
617, —1, 
τ 
624 5-1 
6267 im] 


Group { 


children [ 
#The center hub of the propeller 
Shape ( 


appearance DEF Bronze Appearance ( 
material Material ( 
Errrtusecolor 1.0 1.0 0.0 
) send material 
) #end appearence 
geometry Cylinder { 
radius 0.7 


height 0.5 
) # end geometry 
b #end shape 
#Blade 1, oriented to stick out of the right side of the 
hub 
DEF Blade Transform { 
rotation 120 0.0 0.0 1.048 
translation 220 0.0 0.0 
scale 240 Oc quU 5 


children Shape { 
appearance USE Bronze 
geometry Sphere {} 

) #епа shape 


jJ idend transform 
#Blade 2 

Transform ( 

rotation 0.0 1.0 0.0 1.26 
children USE Blade 

1, 

#Blade 3 

Transform ( 

rotation 0.10 1.0 0.0 2152 
children USE Blade 


#Blade 4 

Transform { 

rotation 0.0 1.0 0.03.78 
children USE Blade 

}, 


#Blade 5 

Transform { 

rotaEl1oni0 51505 0 0 5.04 
children USE Blade 

) 


] # end of children in group 
) # end of Propeller Group 
hes #end of propeller_position Transform 


DEF Blade_Clock TimeSensor { 
cycleInterval 3.0 
startTime 1:0 

loop TRUE 

irs 

DEF Blade Path OrientationInterpolator ( 
Iesus 1550.27.03, 0-4,900955» 0.6, 0.7, 0.8, 0.9] 
keyValue [0.0 1.0 0.0 0.0, 


omom 07070 0.628, 
OMOTO 0 1.256; 
Оо 1.884, 
gd 9.0.0 2.512, 
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νυ. ο ο ο 3.14, 

ОТСО 0.03 το 
ОО ТО 0.0 4439367; 
0.0 1.00.0 5.024; 
0051.0 0.0 35-552] 


] 


) 
#The Vortex Dissipater 
Transform { 
translation 182.5 -7.5 9.5 
rotation 0.0 0.0 1.0 =15 
children Shape { 
appearance Appearance { 
material USE , 688 Hull 


geometry Cone ( 
height 6.0 
bottomRadius 1.7 


), 


#This section creates the periscope 
Transform { 
translation -76.0 32.0 10.0 


children [ 
Shape ( 
appearance Appearance { 
material DEF Scope_color Material { 
diffuseColor (O 75.0 75 ο. 15 
} 
j 
geometry Cylinder ( 
radius 0.2 
height 9.0 
} 
Ls 


Transform ( 
translation -0.2 4.3 0.0 
scale 1.2 1.0 0.80 
children Shape ( 
appearance Appearance ( 
material USE Scope_color 
) 
geometry Cylinder ( 
radius 0.3 
height 0.4 


) 


ROUTE Blade Clock.fraction changed TO Blade Path.set fraction 
ROUTE Blade Path.value changed TO propeller movement.set rotation 
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5. Phoenix_auv.wrl 
#VRML V2.0 utf8 


#Model of the Naval Postgraduate School Center for Autonomous 
# Underwater Vehicle (AUV) Research's "Phoenix" AUV. 
# Authors: Martin Whitfield, Don Brutzman, Kevin Byrne 


Viewpoint { 
bosition 0 0 2 
orientation 01 0 O0 
description "Stbd Beam" 
) 


Viewpoint ( 
position 2 0 2 
orientation 0 1 0 .707 
description "Stbd Bow" 
) 


Viewpoint ( 
position 2 0 0 
orientation 0101.4 
description "Bow" 


) 


Viewpoint ( 
position 2 0 -2 
orientation 0 1 O 2.3562 
description "Port Bow" 


) 


Viewpoint { 
position O O -2 
orientation 0 10 3.14159267 
description "Port Beam" 


) 


Viewpoint ( 
position -2 O -2 
orientation 0 10 3.9270 
description "Astern Port" 


) 


Viewpoint { 
position -2 0 0 
orientation 0 10 -1.4 
description "Astern" 


) 


Viewpoint ( 
position -2 02 
orientation 0 1 0 -.707 
description "Astern Stbd" 


) 


Viewpoint { 
Position 0 0 2 
orientation 010 0 
description "Stbd Beam" 


) 


Viewpoint ( 
position O 1.5 1.5 
orientation 1 O O -.707 
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description "Above 


) 


Viewpoint { 
position 2 2 2 
orientation -.6786 
description "Above 


) 


Viewpoint ( 
position 2 270 
orientation -.3574 
description "Above 


) 


Viewpoint { 
position 2 2 -2 
orientation -.3780 
description "Above 


Stbd Beam" 


26796 — 281i 1.0961 
Stbd Bow" 


ο ОУ 3574 1.7178 
Bow" 
85125-1565 294199 


Port Bow" 


) 


Viewpoint { 


position O 2 -2 


orientation 
description 


) 


Viewpoint { 
position -2 
orientation 
description 


| 


Viewpoint { 
position -2 
orientation 
description 


} 


Viewpoint { 


position -1. 


orientation 
description 


) 


Viewpoint { 
position -2 
orientation 
description 


Viewpoint { 
position -1 
orientation 
description 

) 


Viewpoint { 
position -1 
orientation 
description 


} 


Viewpoint { 


155070. 3.9270 
"Above Port Beam" 


2 -2 
-.1566 .9125 .3780 3.8643 
"Above Astern Port" 


2 0 
.3574 .8629 
"Above Stern" 


.3574 4.5654 


5. 090 
0 1l 0 -1.4 
"Close Astern" 


DS 
0 1 0 =.707 
"Close Astern Stbd" 


ОБ 


0100 
"Close Stbd Stern" 


ΠΗ», 


οἱ: @ 0 
"Stbd Stern" 
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position O =1.5 1.5 
orientation 1 0 0 .707 
description "Below Stbd Beam" 


) 


NavigationInfo { 
type [ "EXAMINE" "ALL" ] 
) 


Group { # DEF AUV 
children [ 


# Fwd Top Plane 

Trans form{ 
translation .6223 .13335 O0 
children[( 


*A Plane Shape 
DEF A, Plane Shape( 
appearance Appearance( 
material Material (diffuseColor .3 .2 0) 
} #end Appearance 
geometry IndexedFaceSet { 
coord Coordinate{ 


ποι... 0635, - 0, -.0127, #0 
80535198 —T1778,- -.0127, #1 
-.0381, 78, -.0127, 82 
-.0889, ο, -.0127, #3 
7063577 07 2012735 #4 

Όσοι, «1115, 501275 #5 
-.0381, 1778, οι”. #6 
-.0889, 0, ОЕА #7 


] #end Points 
) #end Coordinates 


coordIndex[ 0, 3, 2, 1, -1, 
ASG m7, =1, 
05. 4, -1, 
ge v5. 57 -1, 
Du ux. 6. -l, 
Drusus 4. -1 


] #end coordIndex 
creaseAngle 3.14159 
} #end IndexedFaceSet 
} #end Shape 
] #end Transform children 
} #end Transform 


# Aft Top Plane 
Trans form{ 
Eranslation -.7747 .13335 0 
children [ 
USE A_Plane 
]$ end Transform children 
}#end Transform 


#Fwd Bottom Plane 
Trans form{ 
rotation 1 0 0 3.14159267 
translation .6223 -.13335 0 
children [ 
USE A_Plane 
]fend Transform children 
)*tend Transform 
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#Aft Bottom Plane 
Transformí 
rotation 1 0 0 3 1241552067 
translation -.7747 -.13335 0 
children[ 
USE A, Plane 
J#end Transform children 
}#end Transform 


#Stbd Fwd Plane 
Trans form{ 
rotation 1 0 0 1.5708 
translation .6223 0 .20955 
children[ 
USE A Plane 
]#епа Transform children 
}#end Transform 


#Stbd Aft Plane 
Trans form{ . 
oration 1 0 0 1.5708 
translation -.7747 0 .20955 
children[ 
USE A_Plane 
J#end Transform children 
}#end Transform 


#Port Fwd Plane 
Trans form{ 
rotation 1 0 0 -1.5708 
translation .6223 0 -.20955 
children [ 
USE A_Plane 
])tend Transform children 
)#end Transform 


#Port Aft Plane 
Transform{ 
rotation 1 0 0 -1.5708 
translation -.7747 0 -.20955 
children [ 
USE A_Plane 
J#end Transform children 
}#end Transform 


#Fwd Vert Thruster 
Trans form{ 
translation .3302 0 0 
children[ 
Shape ( 
appearance Appearance ( 
material Material (diffuseColor .2 
) 
geometry Cylinder (height .29 radius 
}#end Shape 
J#end Children 
}#end Transform 


#Aft Vert Thruster 
Trans form{ 
translation -.4953 0 0 
children[ 
Shape ( 
appearance Appearance (( 
material Material (diffuseColor .2 


z 2 2) 


.0635) # (height 


220229 
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.2737 radius 0655] 


) 
geometry Cylinder {height .29 radius .0635} # (height .2737 radius .0635) 
}#end Shape 
])tend Children 
}#end Transform 


#Fwd Horiz Thruster 
Transform( 
rotation l1 0 0 1.5708 
translation .4699 0 0 
children [ 
Shape ( 
appearance Appearance( 
material Material (diffuseColor .2 .2 .2) 
) 
geometry Cylinder (height .44 radius .0635) # {height .4231 radius .0635} 
}#end Shape 
}#end Children 
}#end Transform 


#Aft Horiz Thruster 
Trans form{ 
rotation 1 0 0 1.5708 
translation —.6223 0 © 
children [ 
Shape { 
appearance Appearance { 
material Material (diffuseColor .2 .2 .2) 
) 
geometry Cylinder (height .44 radius .0635) # (height .4231 radius .0635) 
) #end Shape 
] #end Children 
) #end Transform 


#Hull 
Group { 
children [ 


#Bow Cowling 
Shape ( 
appearance Appearance ( 
material Material (diffuseColor 0 0 .8) 
) tend Appearance 


geometry IndexedFaceSet ( 
coord Coordinate( 


роїпС[ . 6985, .13335, -.20955, #0 Start of Bow Cowling 
.6985, E355, "209557 #1 
111335, .20955, #2 
6955, -.13335, -.20955, #3 
ο HOSS 075 #4 
0579770 1114... $5 
1205298 085, 0, #6 
qM 65, o -.1143, #7 
1-05; 202572. -. 098985, #8 
1057 .079188, -.05715, #9 
1.055 .079188, £057 lS. #10 
1057 201572. . 098985, #11 
jn 0558504572; . 098985, #12 
1.05, -.079188, .05715, #13 
1.05, -.079188, -.05715, #14 
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1:05. —040572. ——.098985, ΠΠ 
13215 .04064, 2020925 #16 
II 702032, . 06096, #17 
1 1257902032, .06096, #18 
1.1, -.04064, «02032, #19 
КОК 04064, . — 02032; #20 
wL, 2502032, -.06096, #21 
Амзе ‚02032, -.06055. #22 
1-10, 04064, —. 020327 #23 
Π.Ι); 70; 0; #24 
= 6985, 133357 20955 #25 Start of Stern Cowling 
-.6985, 21:533 357 20955 #26 
-.6985, 3 31315. 20955 #27 
-.6985, 1.5. 20955 #28 
J] 3053 Ὁ 20955, 429 
-1503035. 05 -.20955, #30 
-.6985, „13335, 0635, #31 Start of Rudder Post 
-.8509, 213335, 0635, #32 
-.8509, „139857 -.0635, $33 
-.6985, ο οσο -. 0635, #34 
-. 6985, -. 13335, 0635, #35 
-.8509, -.13335, „0635, #36 
-.8509, -.13335, -.0635, #37 
-.6985, -.13335, -.0635, #38 
] #end Points 
} #end Coordinates 
coordIndex[ 0,.265, 34, 3322325731, δι Ἱ  -Ὁτ πο 
15.25.0720. 0285 7250 Les 
2, 28,35, 36, 37,38, 27, 3,-1; 
0,943; 20 03026 ls 
бе P 15 #Bow Cowling 
σα τι d -ι 
Ἱ ο, 2 ΕΙ. 
T: 27 —15 
dabo MJ re 
2,93 On a 
dog. бу = 
ЗУ ОТЕ 
τ ος. 
νο ο τι 
8, 0, 9, =1; 
5 σι ο 1. 
ο ο, ᾱ 1s 
9 2 90 0-1» 
4. 2, τοι 
4, 10; ЕЕ 
10, 2178 DIE 
О 
11, О 57617 
πα, S5 1 т 
55 2: 12 -F 
5 412 ЕЯ 
12. 2; 13 s 
Па ТЭСО жү 
τι: 72.6, 
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13; 6, e -1, 
СЗ 14, =, 
ου τα, 3, -1, 
qup See bee -1, 
Ix 15, dm -1, 
15 3 7; -1 
Tm a D -1, 
JT T6, -1, 
DOC IT. 16, -1, 
EM 5 17, -1, 
Sree, 18, -1ι, 
ears eo, -1, 
πο. 19 =l, 
6, 14, 20, -1, 
TAIS 2205-1, 
Sr απ 2I  -1, 
ο 5-5. I, 
8, 9, 23, -1, 
9 4; 23, -1, 
1516523 51, 
JE x17 τς, =й, 
Segoe ky, =1, 
pog 15. -1, 
ο. 2ο. 19-1, 
20. 15 21, -, 
2] ΗΒ -1, 
ο. 23,7 -Ἡ, 
Qu σαν τα, mI, 
d η 54. -1, 
ПШ 4879224. = 
18, 19 23, .-1, 
15. το. ο =l, 
20, 21 οἳ 5, 
21, 22,922 -1, 
22, 231209249 —1, 
264 οὐ ЗО, =1, #Start of Stern Cowling 
257.26 30; 29, -1, 
25 40205228 -1, 
27 ο ο 3, --α, 
31, 32, 36, 35, -1, #Start of Rudder Post 
40 2395327 236.1, 
34,039 9975733, =1, 


) 4end coordIndex 
creaseAngle 3.14159 


} #end IndexedFaceSet 
} #end Shape 


) #end Hull Group Children 
} #end Hull Group 


#The Stbd screw 
Trans form{ 
translation -1.1557 0 
children [ 
Group { 
children [ 


209525 


# DEF Stbd_Screw 
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DEF Stbd Blade Groupí 
children[ 
Transform{ 
rotation 0 1 0 -.39 
children[ 
Shape { 
appearance Appearance ( 
material Material (diffuseColor .226 .197 0} 
) #end Appearance 


geometry IndexedFaceSet ( 
coord Coordinate( 


Borne! 0, 0, = 00508; #0 

ο, . 02540, — 2102/0532. #1 
0, +. 04572, = 00524, #2 
ο, 05080, = 00508; #3 
OF „05080, “00508, #4 
D "04572; 200524, #5 
0, .02540, 202032; #6 
Ὁ, . 00508 #7 


] #end Points 
y #end Coordinates 


coordIndex[. 0,919492 75 2 ο οι 
0, το 1, -1 
] *end coordIndex 
) tend IndexedFaceSet 
) 4dend A Blade Shape 
J#end transform children 
} #епа transform 
] #end group children 
} #end A_Blade Group 


- - 


Transformí 
rotation 1 0 0 1.5708 
children[ USE Stbd Blade ] 
) #end Transform 


Transform( 
rotation 1 0 0 3.14159267 
children[ USE Stbd Blade ] 
) #end Transform 


Transform( 
rotation 1 0 0 -1.5708 
children[ USE Stbd Blade ] 
) #tend Transform 


#The shaft 
Transform{ 
rotation 0 0 1 1.5708 
translation .0281 0 0 
children [ 
Shape { 
appearance Appearance { 
material Material (diffuseColor .226 .197 0} 
} #end Appearance 
geometry Cylinder {radius .008 height .0762} 
} #end Shape 
] #end children 
} #end Transform 


#The shaft end cap 


Transform{ 
rotation 0 0 1 1.5708 
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translation -—.015 0 0 
children [ 
Shape { 
appearance Appearance { 
material Material (diffuseColor .226 .197 0) 
) *end Appearance 
geometry Cone (bottomRadius .008 height .01) 
} #end Shape 
] #end children 
} #end Transform 
} #end Screw Group Children 
} #end Screw Group 
] #end Transform Children 
} #end Transform 


#The Port screw 
Transform{ 
translation -1.1557 0 -.09525 
children|[ 
Group { # DEF Port Screw 
children [ 


DEF Port_Blade Group{ 
children [ 
Transform{ 
EoObabtion 0 1-0 39 
children[( 
Shape ( 
appearance Appearance { 
material Material (diffuseColor .226 .197 0} 
} #end Appearance 


geometry IndexedFaceSet { 
coord Coordinate { 


Pointl O O, -.00508, #0 

0, ‚02540, -.02032, #1 
0, 20465072 21—07524., 12 
ο. 2050805 -.00508, 13 
ο. «05080, 200508, #4 
0, .045 79, "O01524; #5 
0, .02540, 02032; #6 
o . 00508 #7 


1 #епа Points 
) tend Coordinates 


соот пдйех[ Ол л; 2, 3, 
ο 5 7 ο 5 oe 3 
] *end coordIndex 
} #end IndexedFaceSet 
} #end A_Blade Shape 
J#end transform children 
} #end transform 
} #end group children 
} #end A_Blade Group 


m 


Trans form{ 
rotation 1 0 0 1.5708 
children[ USE Port Blade ] 
} #end Transform 


Transform{ 
rotation 1 0 0 3.14159267 
children[ USE Port Blade ] 
} #end Transform 


-163- 


Transform{ 
rotation R0 0 -1.5708 
children[ USE Port Blade ] 
} #end Transform 


#The shaft 
Transform{ 
rotation. 0 0 1 1.5708 
translation .0281 0 0 
children [ 
Shape { 
appearance Appearance{ 
material Material {diffuseColor .226 .197 0} 
} #end Appearance 
geometry Cylinder {radius .008 height .0762} 
} #end Shape 
] #end children 
} #end Transform 


#The shaft end cap 
Transform{ 
rocacion 0 0 1 1.5708 
translation -.015 0 O0 
children[ 
Shape { 
appearance Appearance { 
material Material {diffuseColor .226 .197 0} 
} #end Appearance 
geometry Cone {bottomRadius .008 height .01) 
} #end Shape 
] *end children 
} #end Transform 
] #end Screw Group Children 
} #end Screw Group 
] #end Transform Children 
} #end Transform 


]#end AUV Group children 
} #end AUV Group 


#end auv.wrl 
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APPENDIX C. EXPERIMENTAL SCRIPTS AND RESULT DATA 


mà 


. Mission.script.SeaStateTest 


your mission is 
Sea State Test 


ж + 


# misslon.script.SeaStateTest 
uu, 


EDS trial position 
position -180 50 2 


# drive straight into seas 
course 000 

depth 2 

rpm 350 


fie test for 5 minutes 
wait 300 


#done, stop 
rpm 0 
wait 60 


# test complete 
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24 Mission.script.FlowFieldTestLoop 


your mission is 
flow field test loop 


+= +E 


# mission.script.FlowFieldTestLoop 
+ rm 


# shift DS30 Precision Doppler Sonar mode 
# to track speed through water, not speed over ground 


T 

# hull is at y distance of 83 feet 
| M OE 

# initial position inside hull 
position 117 88 43 

orientation 0 O 335 
standoff-distance 2.0 

# launch from lower port torpedo tube 
Bover 122 85.943 335 

wait 10 

# drive out of tube 

rpm 700 

wait 20 


# до to surface and turn south 


depth 2 
course 180 
wait 90 


# Operate at surface first, then go deep 
rpm 0 
wait 60 


thrusters-on 


rpm 700 
depth 70 
wait 60 


4 drive to aft end of submarine 
standoff-distance 4.0 
hover -130 75 33 000 
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# steer collision avoidance sonar 
# to track the submarine hull 
SONAR_725 090 30 1 


# wider scan for tracking sonar 
SCAN-WIDTH 45 


wait 10 
hover-off 


# take position just aft of the pump discharge 


rpm 400 
course 000 
depth 33 
wait 60 


# stabilize after pump discharge 
waypoint -25 76 33 


# drive through pump suction 
course 000 


rpm 400 
depth B3 
wait 5 


# stabilize after pump suction 
waypoint 90 80 33 


# dock with torpedo upper port tube, 
# then hover with nose in tube 


Endorf-distance 0.5 

course 025 

hover 1089555942733 

# move in 

hover 11; como 

# Stabilize for next iteration 
wait 10 


hover-off 


$ docking complete 
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8. X VERSUS Y FOR NO-FLOW SIMULATION 
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APPENDIX D. FLOW GENERATION CODE 


ШОО ο ο ο. ο. ο. ου... ο... ου. ο ο ο ου 7////////////////7/7/]/ 
/* 
Program: FlowFieldGenerator.C 


Description: This program creates the data required for a complex flow field 
associated with a submarine driving through the water. It uses 
Flat Plate Fluid Flow theory to create a series of files which 
contain the data used by the Phoenix AUVs Virtual environment. 


This program is based upon a program which was written in fortran 
called ITBL (Incompressible Turbulent Boundary Layer) froma 
mechanical Engineering text. The book was called Boundary Layer 
Analysis, by Joseph A. Schetz. 


Revised: 26 January 98 

System: τι: 5.3 

Compiler: ANSI C++ 

Compilation: irix» make FlowFieldGenerator.o 


irix» CC FlowFieldGenerator.C -lm -c -g +w 


-с == Produce binaries only, suppressing the link phase. 
*w -- Warn about all questionable constructs. 

Author: Kevin Byrne 

Thesis: Byrne, Kevin M., Real-Time Modeling of Cross-Body 


Flow for Torpedo Tube Recovery of the Phoenix Autonomous 
Underwater Vehicle, Masters Thesis, Naval Postgraduate 
School, Monterey California, March 1998. 


Advisors: Dr. Don Brutzman, Dr. Bob McGhee 
References: Schetz, Joseph A., | Boundary Layer Analysis, , 
Prentice Hall, Englewood Cliffs, NJ, 1992. 
Notes: 
"s 2-d Boundary Layer Computation,  Incompressible, 
/ / Bmurbulent, lst Order, Implicit 
/ 
Va Mixing-length or Eddy-viscosity Model or Tke Model. 
4 
II. Equations Are Dimensionless Using Freestream Velocity, 
// Uinf, Viscosity, Muinf, and Density, Rhoinf, and a 
А Reference Length, L; X/1, Y/1, U/uinf, Also 
/ Re - Rhoinf*uinf*l/muinf 
n Pick L= 1.0. 
А 
// Other Variables: 
/ / Rkap, Kappa in the Mean Flow Turbulence Models 
"n Ypa, Y Sub A- 
Sy Del, Starting Boundary Layer Thickness 
А Duedx, Derivative of Edge Velocity in the X Direction 
i Red, Reynolds Number Based on Delta 
if Usue, Ustar/uedge 
Г A,b,c, Splitting up the Boundary Layer Equations 
КА 
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ү Sample Problem of a Flat Plate with Uinf - 10.0. Start at 


"mi X 2 5.0. Goto χ 56 Take Nu(smuin£/rhoint)ssei1 0e-5"WRexS5"0e5- 
zz 

Lf Use Simple Integral Solution to Get Initial Values. 

74 Delta = 0.0856. Cf = 0.002665. Other Flows Can Be Set by User. 


IT TC TT IT IP LP LT ETT TITALL E EDEDDILIIEEEEM νυ  ;;;;, 


#include <iostream.h> 
#include <iomanip.h> 

#include <fstream.h> 

#include <math.h> 


#define TRUE 1 
#define FALSE 0 


struct FlowGridElements { 


double direction; //direction relative to sub heading 
double x_magnitude; //The magnitudes are dimensionless 
double y_magnitude; //forces in the submarine reference frame 


double z_magnitude; 


I3 


const int FLOWFIELDLENGTH 
const int FLOWFIELDWIDTH 


721; 342v * 2enghtoof subsomP 5 fb ire 
615 //4 * the number of cross, sections on AUV 


l Il 


//These grids are used to pass the initial flow profile from the flat 
//Plate model to the tube level model. The tube level model refines 
//these arraysin the areas of interest. 

FlowGridElements globallktgrid[FLOWFIELDLENGTH] [FLOWFIELDWIDTH] 
FlowGridElements global2ktgrid[FLOWFIELDLENGTH] [FLOWFIELDWIDTH] 
FlowGridElements global3ktgrid[FLOWFIELDLENGTH] [FLOWFIELDWIDTH] 


{0); 
(0): 
{0}; 


//Local Constants 
const double RKAP = 0.41; 
const double YPA = 9.7; 


[[--—------------------------------2-4-----------------2-2------2-----2-----2----- 
void eddy( int NNX, int MMAX, int MEST, const double RE, double DY, 
double U0[], double UE[], double T[], double CF[]) ( 

double RMUT 59:505 

double 0 = ООК 

double YP z 0.0; 

double DEDST = 0.0; 

for (int ie = 2; ie <= MEST; ie++) ( 


DELST = DELST + DY*(1.0-0.5* (U0[ie-1]+U0 [ie] ) /UE[NNX]); 
) 


/ / CLAUSER EDDY VISCOSITY MODEL 
RMUT = 0.018*RE*UE[NNX] *DELST; 
for (int ig = 1; ig <= MMAX; igt+) { 


Y 
ҮР 


(1G=1 * DY; 
Y*UE[NNX] *RE*sqrt(0.5*CF[NNX-1]); 


/ /REICHART MODEL FOR COMPLETE INNER REGION 
T[ig] » RKAP*(YP-YPA*tanh(YP/YPA)); 
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if (T[ig) » RMUT) { 
TIG “ΕΜΠ; 
) 
) 


return; 


) //end of function eddy 


void TRID ( int MM, double A[], double B[], double C[], double R[], double S[]) { 


double GAM[550]; 
double RP[550]; 
double DENO; 


// | THOMAS ALGORITHM 
GAM[1] = C[1] / в[1]; 
Fi [TJ = R[1] / B[1]; 


for (int ih = 2; lh <= MM; ih++) ( 
DENO - B[ih] - A[ih] * GAM[ih-1]; 
GAM[ih] » C[ih] / DENO; 
RP[ih] » (R[ih]-A[ih]*RP[ih-1]) / DENO; 
) 
S[MM] - RP[MM]; 


fom (int ii 
S[MM-11i] 


1; 11 <= ММ-1; 11++) { 
RP[MM-11]-GAM[MM-11]*S[MM-11i-1]; 


) 
return; 


) //end of function TRID 


EN ее сс —— ——— 
void flatPlateFlowFieldGenerator ( void ) { 

А YOU MUST GIVE INITIAL X (XI), FINAL X (XF), (CNU), (UNINF), 

ή (NMAX), (MMAX) AND (DY) 

2 PICK MMAX BASED ON INITIAL BOUNDARY LAYER THICKNESS AND 

^ NUMBER OF POINTS ACROSS THE LAYER. USE AT LEAST 400 ACROSS 

Jt DELTA. ADD AT LEAST 100 POINTS ABOVE DELTA. 

αν 

// PICK NMAX BASED ON LENGTH OF REGION AND DX DESIRED. DX 

τα CAN BE OF THE ORDER OF INITIAL DELTA/FIVE. TAKE L = 1.0. 


//Constant Variables 
const int ARRAY, SIZE 50; 


= 5 
const double “ιο //Initial X position where flow hits plate 
const double ο ου σι, 
//Nariables I needed to add for iteration down sub Hull 


int current. distance up 


int index difference О; 
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double submarine length meters 
//double submarine speed 


-— 


111; //Length in meters 360 ftostruly τος 7m 


quos 


struct flowRecord ( 


double 

double 

double 

double 
J; 


x_magnitude; 
_magnitude; 

z_magnitude; 

direction; 


flowRecord nontubelevelgrid[FLOWFIELDLENGTH] [FLOWFIELDWIDTH] ; 


//Array declararations 


double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 
double 


U[ARRAY. SIZE]; 
UO [ARRAY. SIZE]; 
V[ARRAY SIZE]; 
VO[ARRAY SIZE]; 
GEDBIS0]1:; 
A[ARRAY. SIZE]; 
B[ARRAY SIZE]; 
C[ARRAY. SIZE]; 
R[ARRAY SIZE]; 
TKEO[ARRAY SIZE]; 
TMU [ARRAY. SIZE]; 
UE[150]; 

DUEDX [150]; 


Y [ARRAY. SIZE]; //distance from hull feet 


//Naribles Required For Fluid Caluations 

int MMAX = 60; //MMAX originally was 525, NMAX originally was 101 

int NMAX = 15; 

ine MEST = 401; //This is the M index for the initial Delta 

Int FM1 = MEST-1; 

ant NMAXP - NMAX; 

nt MMAXP = MEST+100; 

Int NNX; 

double XF - 0.0; //The position at which the profile is generated 

double DY - 0.02/MMAX; // step distance away from hull per calcualtion(last 
value.035) 

double DX: // distance from the start of plate 

double DENO; 

double DEL = 0.00015; 

double хор; 

double pump outlet jet factor; //Holds value for pump force reduction sw 
discharge 

double pump inlet jet factor; //Holds value for pump force reductionsw suction 

double pump outlet jet speed = 2.5; //Holds value for pump force (knots) 

double pump inlet jet speed - 1.0; //Holds value for pump force (knots) 

double pumpSuctionPosition ft - 180.5; //The position along hte hull of suction 
СЕЕ) 

double pumpDischargePosition ft - 245.5; //The position along hte hull of discharge 
(ft) 

double suctionBegin m - (pumpSuctionPosition ft - 6.5) * 0.3048; //Begin of 
suction forces (m) 

double suctionEnd m - (pumpSuctionPosition ft + 6.5) * 0.3048; //End of Suctiem 
forces (m) 

double dischargeBegin_m = (pumpDischargePosition_ft - 6.5) * 0.3048; //Begin of 
discharge forces(m) 

double dischargeEnd_m = (pumpDischargePosition_ft + 6.5) * 0.3048; //End of 
discharge forces (m) 
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//Output streams to hold the generated flow fields for later usage 


di flatplateflowfieldlkt.data - Holds the entire flatplate model flow field 
/ 4 for a submarine speed of 1 kt. 

/ / flatplateflowfield2kt.data - Holds the entire flatplate model flow field 
/ / for a submarine speed of 2 kt. 

nr flatplateflowfield3kt.data - Holds the entire flatplate model flow field 
vf for a submarine speed of 3 kt. 

// 

D, These others are just for data verification. 

/ / flatprofile.data - Holds flat plate data for sub profile 

// flatslice50.data - Holds flat plate data for slice at 50 ft 

as flatslicel00.data - Holds flat plate data for slice at 100 ft 

А flatslicel50.data - Holds flat plate data for slice at 150 ft 

// flatslice200.data - Holds flat plate data for slice at 200 ft 

// flatslice250.data - Holds flat plate data for slice at 250 ft 


ofstream platelktOutput ("flatplateflowfieldlkt.data", ios::out); 
ofstream plate2ktOutput ("flatplateflowfield2kt.data", ios::out); 
ofstream plate3ktOutput ("flatplateflowfield3kt.data", ios::out); 
ofstream plateProfileOutput ("flatprofile.data", ios::out); 
ofstream plateSlice50O0utput ("flatslice50.data", ios::out); 
ofstream plateSlicel000utput ("flatslicel00.data", ios::out); 
ofstream plateSlicel500utput ("flatslicel50.data", ios::out); 
ofstream plateSlice200O0utput("flatslice200.data", ios::out); 
ofstream plateSlice2500utput ("flatslice250.data", ios::out); 


for (int submarine speed - 1; submarine_speed < 4; submarine_speed++) { 


int last distance filled - 0; 


double UINF -» (double)submarine speed; //This is the flow strength in open water 
//This declared here due to dependence on other variables 

double RE - UINF * submarine length meters / CNU; 
}/----------------------------------------------------------------- 


//Initialize flow field to zero prior to each speed iteration 
for ( int row - 0; row < FLOWFIELDLENGTH; row++) { 
for (int col = 1; col < FLOWFIELDWIDTH; col++) { 


nontubelevelgrid[row][col].x magnitude - 0.0; 
nontubelevelgrid[row][col].y magnitude = 0.0; 
nontubelevelgrid[row][col].z magnitude = 0.0; 
nontubelevelgrid[row][col].direction = 180.0; 
) 
) 
}/------------------------------------------------------------------ 


//This is the main loop. It generates the Flow field from bow to stern 

//in 1 meter increments. Each profile starts from the hull and 

//goes outward until flow force - Uinf (-30 ft) 

for (int generationloop - 1; generationloop « submarine length meters ; 
generationlooptt) { 


//Flag for file output 

"HA XtirsrtEnEry z 1; 

//This increments XF by 1 m each time. The loop will run from bow to stern 
XF - (double)generationloop; 

DX - (XF-XI) / (NMAX-1); 


//initialize UE and DUEDX arrays they are only 150 elements large 
for ( int iw = 0; iw <= NMAX; iw++) ( 
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UE[iw] 
DUEDX [ iw] 
) 


w `. 


"f I 
СЕ, 
о о 


//additional variable which depend on nitialized arrays 
CF[I] = ο ας 

double USUE = sqrt(CF[1]/2.0); 

Gouble RED = RE * DEL * USUE * UE[1]; 


//initialize other arrays, these are 550 elements large 
for τοι ο 1; ix <= MMAX  їх++) [ 


U[ix] = UE[1]; 
Ulixi πιεί]: 
V[ix] = 0.0; 
VO[ix] EE): 
TEROERTZx]- - 0.0; 
TMU[ix] ο ο, 
) 
"ny NO SLIP CONDITION 
Ur] -2-0.0 


//The initial profiles of U and V can be changed by the user. 
//MEST is the M index for the initial Delta. 
//Assume a Coles Wake Law Initial Velocity Profile 


for (int iy = 2; iy <= MEST? ayer) { 


YOD = (double) (iy-1) / (double) FM1; 
UO[iy] = USUE*UE[1]* 
(1.0/RKAP*log(YOD*RED) + 4.90 + 0.51/RKAP 
* 2.0 pow( Sin (Y0D+]1 57085) 2}; 
ολ. Ἱ -αᾱα 


//By this point all initialization is done, UO and VO are initial U+V profiles 
int done 200 = FALSE; 


nt iz = pr 

while (( iz «- NMAX ) && (done 200 == FALSE)) { 
ΝΝΧ - 12; 
U0 [MMAX] = UE[iz]; 
VO ([MMAX] = 0.0; 


еса MMAX, MEST, RB, DY, 00, UE, TMU, CF); 


Bi) 
ОГ 
EM 
A[MMAX] 
B[MMAX] 
C[MMAX] 
R[MMAX] UF[12] ; 
DENO - RE*DY*DY; 


d 
Be 
0. 


H H n N 
e 
eo 


for (int ia 2; ia <= MMAX-1; la++) ( 


Alia] 
B[1a] 


-0.5*vO[ia]/DY-(1.0-TMU[ia-1])/DENO; 
U0 [ia] /DX+ (2.0+TMU[ia-1]+TMU[ia] ) /DENO; 
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C[1a] 
R[ia] 


0.5*VO[ia] /DY-(1.0+TMU[ia] ) /DENO; 
UE[iz]*DUEDX[iz]-*UO[ia]*UO[ia]/DX; 


) 
TRID(MMAX, A, B, C, R, U); 


for (int ib = 2; iD: = MMAX - 1; ib++) í 
v[ib) = V[ib-1]-(0.5*DY/DX)* (U[ib]-UO[ib]+U[ib-1]-U0[ib-1]); 
) 


int done = FALSE; 
int ic = MEST - 10; 


while ((ic <= MMAX) && (done == FALSE)) { 
if (Ulici >- 07 99*UE[iz]} { 
MEST πα, 
MMAXP = MEST+100; 
done = TRUE; 
) 


іс++; 


) 


//This steps in the X-direction from front of plate to current position 
for (int id = 2; 1@ <= MMAX; idt-*) { 


U0[id] 
VO [id] 


υ [1] ; 
V[id]; 


CF[iz] - (4.0*U0[2]-U0[3]) / (pow(UE[iz],2) *DY*RE); 


//Check if near Seperation, if so this profile is done 
ree (CF (um) e0-0001) { 


NMAXP - iz; 

done 200 = TRUE; 
) 
12++; 


) //end of for 200 loop 


if (MMAXP > MMAX) { 
MMAXP - MMAX; 


//This section puts data in seperate files for later use. 
//The data is formatted in the following order: 


/ / X-dir flow component Y-dir Z-dir vector direction 
//All values are unitless. This allows scaling during usage. 
M 


//Calculate the number of feet down the hull we are 
current_distance = (int) (generationloop/.3048) * 2; 


//Check to ensure we have a good ft increment on hull 

JI (current distarce > 720 ) { 
cout << " Distance along hull exceeded 360 ft, reset to 360 ft (720)" << endl; 
current distance - 720; 


) 


if (current. distance « O ) ( 
cout «« " Distance along hull below 0 ft, reset to 1" «« endl; 
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current distance = 70 


) 


//Calculate the number of rows to be filled.This is needed because the 
//dynamics model needs a flow field with 0.5 ft increments, and this 
//generates a field of 1 meter increments. We interpolate to fill 

//in the missing data 

index difference - current distance - last distance filled; 


//Output routine to put Values in proper arrays and files 

//A loop is used to access each U value for this position on 
//Hull. The generationloop index represents the distance along 
// the hull in meters 

Тот Ооп τι - ο, ij « MMAXP; 1Π11}. { 


//Distance from the hull in feet 
Y[1j] 2-(ij-1)*DY* submarine length meters / 0.3048 ; 


//This section does array output 

//output of flow field into flowfield arrays 

//We must fill all .5 ft incremented array rows between 
//current distance and last distance filled 


int pass = 1; 
for (int arrayindex = last distance filled + 1; arrayindex < current_distance; 
arrayindex++) { 


// The output data is given in knots based on submarine speed. Dynamics 
converts it to ft/sec 

// To convert knots to ft/sec kts*2000*3/60/60= 1.6667 

//In order to get this force into true x, y, Z components it is necessary to 
multiply the components 

//by a factor which relates them to the sub's refernce frame. Since for the 
flat plate model 

//I assume x and z components are zero, only Y is adjusted . For the tube 
level profile when 

//fully integrated each component will need to be adjusted. 


//reset pump jet force to one 


pump outlet jet factor - 1.0; 
pump inlet jet factor = -1.0; 


for (int column = 0; column < FLOWFIELDWIDTH; column++) { 


nontubelevelgrid[arrayindex] [column] .x_magnitude = 0.0; 

nontubelevelgrid[arrayindex] [column] .y_magnitude = - U[column] * 
submarine_speed; 

nontubelevelgrid[arrayindex][column].z magnitude = 0.0; 

nontubelevelgrid[arrayindex][column].direction = 180.0; 


//This section adds a pump inlet 180 ft back on the hull. It starts out at 
Full 
//force and diminishes to 0 at 20 ft out from the hull. It assumes water is 
sucked in at 2.5 kts 
if ((generationloop » suctionBegin m) && (generationloop « suctionEnd m)) { 
nontubelevelgrid[arrayindex][column].x magnitude - pump inlet jet, factor 
* pump inlet jet speed; 


if (pump inlet, jet factor « -0.2) ( 
pump inlet, jet factor - pump, inlet, jet factor + 0.025; 
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) 
else ( 

pump .inlet jet factor - 0.0; 
) 


//This section adds a pump discharge jet 246 ft back on the hull. It starts 
eae at full 
//force and diminishes to 0 at 20 ft out from the hull.It assumes water is 
discharged in at 2.5 kts 
else if ((generationloop » dischargeBegin m) && (generationloop « 
dischargeEnd m)) { 
nontubelevelgrid[arrayindex][column].x magnitude - pump outlet jet factor 
* pump outlet jet, speed; 


if (pump outlet jet factor > 0.2) { 
pump. outlet jet factor - pump outlet, jet factor - 0.025; 
) 
else ( 
pump outlet jet factor = 0.0; 
) 


//Now write these values to the proper file 
switch ((int)submarine speed) ( 


case 1: 
platelktOutput << arrayindex << "* " «« column «« " " 
«« nontubelevelgrid[arrayindex][column].x magnitude «« 


«« nontubelevelgrid[arrayindex][column].y magnitude «« 
<< nontubelevelgrid[arrayindex] [column] .z_magnitude << 


<< nontubelevelgridf{arrayindex] [column] .direction 
<< endl; 


//Update the global array 

globaliktgrid[arrayindex] [column] .x_magnitude 
nontubelevelgrid[arrayindex] [column] .x_magnitude; 

globallktgrid[arrayindex][column].y. magnitude 
nontubelevelgrid[arrayindex][column].y magnitude; 

globallktgrid[arrayindex][column].z. magnitude 
nontubelevelgrid[arrayindex][column].z, magnitude; 

globallktgrid[arrayindex][column].direction 
nontubelevelgrid[arrayindex] [column] .direction; 

break; 

case 2: 
plate2ktOutput << arrayindex << " " << column << " " 
<< nontubelevelgrid[arrayindex] [column] .x_magnitude << 


II 


<< montubelevelgrid[arrayindex] [column] .y_magnitude << 
«« nontubelevelgrid[arrayindex][column].z magnitude «« 


<< nontubelevelgrid[arrayindex] [column] .direction 
<< endl; 


//Update the global array 
global2ktgrid[arrayindex] [column] .x_magnitude = 
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nontubelevelgrid[arrayindex] [column].x magnitude; 
global2ktgrid[arrayindex] [column] .y_magnitude = 
nontubelevelgrid[arrayindex] [column] .y_magnitude; 


global2ktgrid[arrayindex] [column] .z_magnitude 
nontubelevelgrid[arrayindex] [column] . z_ 
global2ktgrid[arrayindex] [column] .direction 


II 


magnitude; 


nontubelevelgrid[arrayindex][columnl.direction; 


break; 
case 3: 
plate3ktOutput << 
<< 


<< 
<< 


<< 
<< 


arrayindex << " " << column << " * 
nontubelevelgrid[arrayindex] [column] .x_magnitude << 


nontubelevelgrid[arrayindex] [column] .y_magnitude << 
nontubelevelgrid[arrayindex] [column] .z_magnitude << 


nontubelevelgrid[arrayindex] [column] .direction 
endl; 


//Update the global array 


global3ktgrid[arrayindex) [column] .x_magnitude 


nontubelevelgrid[arrayindex]) [column] .x_magnitude; 


global3ktgrid[arrayindex] [column] .y_magnitude 


II 


nontubelevelgrid[arrayindex] [column]. y. magnitude; 


global3ktgrid[arrayindex) [column] .z_magnitude 


nontubelevelgrid[arrayindex] [column] .z_magnitude; 


global3ktgrid[arrayindex] [column] .direction 


nontubelevelgrid[arrayindex] [column] .direction; 


break; 
default: 


cerr << "Invalid Submarine Speed" << endl; 


break; 
} // end switch 
) //end of column loop 
pass += 1; 


) 


//Fill current distance array, 


and write values to file 


nontubelevelgrid[current distance][ij].x magnitude = 0.0; 


nontubelevelgrid[current distance][ijl.y magnitude - 
nontubelevelgrid[current distance][ij].z magnitude = 
nontubelevelgrid[current_distance] [ij].direction = 180.0; 


- U[ij] * submarine speed; 
ο; 


//This section adds a pump inlet 180 ft back on the hull. It starts out at 


full 


//force and diminishes to 0 at 20 ft out from the hull. It assumes water is 


sucked in at 2.5 kts 


if ((generationloop » suctionBegin m) && (generationloop « suctionEnd m)) { 
nontubelevelgrid[current distance][ijl.x magnitude = 


pump inlet jet factor 


* pump inlet jet speed; 


if (pump. inlet jet factor « -0.2) ( 
pump inlet jet factor - pump inlet jet factor + 0.025; 


) 
else ( 


pump inlet, jet factor = 0.0; 


) 


-190- 


//This section adds a pump discharge jet 246 ft back on the hull. It starts 
out at full 

//force and diminishes to 0 at 20 ft out from the hull.It assumes water is 
discharged in at 2.5 kts 

else if ((generationloop » dischargeBegin m) && (generationloop « 
dischargeEnd m)) { 

nontubelevelgrid[current distance][ij]l.x magnitude - 
pump outlet jet factor 
* pump. outlet jet speed; 


if (pumpsoubrPet-jet factor > 0.2) ἱ 
pump outlet, jet, factor - pump outlet jet factor - 0.025; 
) 
else ( 
pump outlet jet factor - 0.0; 
) 


//Now write these values to the proper file 
switch ((int)submarine speed) ( 
case 1: 
platelktOutput «« current distance «« " "«« ij «« " " 

«« nontubelevelgrid[current distance][ij].x magnitude «« " " 
«« nontubelevelgrid[current distance][ijl.y magnitude << " " 
«« nontubelevelgrid[current distance][ijl.z magnitude «« " " 
«« nontubelevelgrid[current distance][ij].direction 
«« endl; 


//Update the global array 

globallktgrid[current distance][ijl.x magnitude - 
nontubelevelgrid[current, distance][1ij].x magnitude; 

globallktgrid[current distance][ij]l.y magnitude 
nontubelevelgrid[current distance][ij]l.y magnitude; 

globallktgrid[current distance][ij]l.z magnitude 
nontubelevelgrid[current distance][ij]l.z magnitude; 

globaliktgrid[current distance][ijl.direction 
nontubelevelgrid[current distance][ijl.direction; 


break; 
case 2: 

plate2ktOutput << current distance << " " << 13 << " " 
<< nontubelevelgrid[current_distance][ij] .x_magnitude << " " 
<< nontubelevelgrid[current_distance] [ij].y_magnitude << " " 
«« nontubelevelgrid[current distance][ij]l.z magnitude «« " " 
«« nontubelevelgrid[current distance][ijl.direction 
«« endl; 


//Update the global array 

global2ktgrid[current distance]íij].x magnitude 
nontubelevelgrid[current distance][ij].x magnitude; 

global2ktgrid[current, distance][ij].y magnitude - 
nontubelevelgrid[current distance][ijl.y magnitude; 

global2ktgrid[current distance][ijl.z magnitude 
nontubelevelgrid[current distance][ij]l.z magnitude; 

global2ktgrid[current distance][ij]l.direction 
nontubelevelgrid[current distance][ijl.direction; 


break; 
case 3: 
plate3kt8tOutput << current_distance << * " << jj << " " 
«« nontubelevelgrid[current distance][ij]l.x magnitude «« " " 
«« nontubelevelgrid[current distance][ijl.y magnitude << " " 
«« nontubelevelgrid[current distance][ijl.z magnitude << " " 
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«« nontubelevelgrid[current distance][ij].direction 
<< endl; 


//Update the global array 
global3ktgrid[current, distance][ij].x magnitude 
nontubelevelgrid[current distance][ij].x magnitude; 
global3ktgrid[current distance][ij].y magnitude = 
nontubelevelgrid[current distance][ij].y magnitude; 
global3ktgrid[current distance][ij]l.z magnitude 
nontubelevelgrid[current distance][ij].z magnitude; 
global3ktgrid[current distance][ijl.direction 
nontubelevelgrid[current distance][ij].direction; 


break; 
default: 
cerr << "Invalid Submarine Speed" << endl; 
break; 
) // end switch 


pass - 1; 
last distance filled - current. distance; 


//This section does file output for files that are used to visualize 
//field output over the whole sub length. They are generally used for 
//viewing only. This data is not in a UVW usable form 


ift που >= 0739) { 
plateProfileOutput << ΧΕ ες”) 
<< V [15] 
<< end1; 


/tirstEDntr P 0. 


//Put output to file for flat plate slice at 50 ft 

if ((generationloop -- 15) && (submarine speed -- 1)) ( 
plateSlice50Output << Y[ij] << " " << U[1j] << endl; 

) 


//Put output to file for flat plate slice at 100 ft 

if ((generationloop -- 30) && (submarine_speed == 1)) ( 
plateSlicel00Output «« Y[ij] << " " << U[ij] << endl; 

) 

//Put output to file for flat plate slice at 150 ft 

if ((generationloop == 45) k&& (submarine speed == 1)) { 
plateSlicel500utput << Y[ij] << " " «« U(ij] << endl; 

} 

//Put output to file for flat plate slice at200 ft 

if ((generationloop -- 60) && (submarine_speed == 1)) { 
plateSlice2000Output << y[ij] << " " << U[{ij] << endl; 

} 

//Put output to file for flat plate slice at 250 ft 

if ((generationloop == 75) && (submarine_speed == 1)) { 
plateSlice2500utput << Y[ij] << " " << U[ij] << endl; 

} 

} 


} //end of generationloop 
} //end of submarine_speed loop 


//Close all output files 
platelktOutput.close(); 
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plate2ktOutput.close(); 
plate3ktOutput.close(); 
plateProfileOutput.close(); 
plateSlice500utput.close(); 
plateSlicel000utput.close(); 
plateSlicel500utput.close(); 
plateSlice2000utput.close() ; 
plateSlice2500utput.close(); 
return; 


) //end of flatPlate function 


void tubeLevelFlowFieldGenerator ( void ) { 


//Arrays to hold all values as they are modified 


FlowGridElements abovelkt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH] ; 
FlowGridElements upperlkt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH] ; 
FlowGridElements centerlkt[FLOWFIELDLENGTH] [FLOWFIELDWIDTH]; 
FlowGridElements lowerlkt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH] ; 
FlowGridElements belowlkt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH]; 


FlowGridElements above2kt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH] ; 
FlowGridElements upper2kt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH]; 
FlowGridElements center2kt[FLOWFIELDLENGTH] [FLOWFIELDWIDTH]; 
FlowGridElements lower2kt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH]; 
FlowGridElements below2kt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH]; 


FlowGridElements above3kt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH]; 
FlowGridElements upper3kt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH] ; 
FlowGridElements center3kt[FLOWFIELDLENGTH] [FLOWFIELDWIDTH]; 
FlowGridElements lower3kt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH]; 
FlowGridElements below3kt [FLOWFIELDLENGTH] [FLOWFIELDWIDTH]; 


//Output streams to hold the generated flow fields for later usage. 
//Five files are created for each sub speed to cover all major variations 
// in flow profile. 


// abovetubelevellkt.data - Holds the tube model flow field at 

LI 1 ft above the tube using a submarine speed of 1 kt. 

/ / uppertubelevellkt.data - Holds the tube model flow field 

m at the upper edge of the tube for a submarine speed of 1 kt. 
{í centertubelevellkt.data - Holds the tube model flow field at 

ts the center of the tube for a submarine speed of 3 kt. 

L4 lowertubelevellkt.data - Holds the tube model flow field at 

ΣΙ the lower edge of the tube for a submarine speed of 1 kt. 
“ή belowtubelevellkt.data - Holds the tube model flow field at 

// 1 ft below the tube using a submarine speed of 1 kt. 

7 


// Files for other speeds are named using the same conventions. 


ofstream abovetubeLevellktOutput  ("abovetubelevellkt.data", ios::out); 
ofstream upperLevellktOutput ("uppertubelevellkt.data", ios::out); 
ofstream centerLevellktOutput ("centertubelevellkt.data", ios::out); 
ofstream lowertubeLevellktOutput  ("lowertubelevellkt.data", ios::out); 
ofstream belowLevellktOutput ("belowtubelevellkt.data", ios::out); 
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ofstream 
ofstream 
ofstream 
ofstream 
ofstream 


ofstream 
ofstream 
ofstream 
ofstream 
ofstream 


abovetubeLevel2ktOutput 
upperLevel2ktOutput 
centerLevel2ktOutput 
lowertubeLevel2ktOutput 
belowLevel2ktOutput 


abovetubeLevel3ktOutput 
upperLevel3ktOutput 
centerLevel3ktOutput 
lowertubeLevel3ktOutput 
belowLevel3ktOutput 


("abovetubelevel2kt.data", ios::out); 
("uppertubelevel2kt.data", ios::out); 
("centertubelevel2kt.data", ios::out); 
("lowertubelevel2kt.data", ios::out); 
("belowtubelevel2kt.data", ios::out); 
("abovetubelevel3kt.data", ios::out); 
("uppertubelevel3kt.data", ios::out); 
("centertubelevel3kt.data", ios::out); 
("lowertubelevel3kt.data", ios::out); 
("belowtubelevel3kt.data", ios::out); 


//Initialeze che tube level flow fields to those of the flat 
//Plate fields 


tor εν 


Готе сог = 


TOW = 0; 
05 


abovelkt 
abovelkt 
abovelkt 
abovelkt 


upperlkt 
upperlkt 
upperlkt 
upperlkt 


[row] [col] 
[row] [col] 
[row] [col] 
[row] [col] 


[row] [col] 
[row] [col] 
[row] [col] 
[του] [σοι] 


.X magnitude 
.y magnitude 
.Z magnitude 
.direction 


.X magnitude 
.y. magnitude 
.Z magnitude 
.direction 


l H H I 


centerlkt 
centerlkt 
centerlkt 
centerlkt 


[row] [col].x magnitude 
[row] [col].y. magnitude 
[row] [col].z magnitude 
[row] [col] .direction 


lowerlkt 
lowerlkt 
lowerilkt 
lowerlkt 


belowilkt 
belowlkt 
belowlkt 
belowlkt 


above2kt 
above2kt 
above2kt 
above2kt 


upper2kt 
upper2kt 
upper2kt 
upper2kt 


[row] [col] 


[row] [col] 
[row] [col] 
[row] [col] 


[row] [col] 
[row] [col] 
[row] [col] 
[row] [co1 ] 


[row] [col] 
[row] [col] 
[row] [col] 
[row] [col] 


[row] [col] 
[row] [col]. 
[row] [col]. 
mowi coisi 


.x_magnitude 


.y_magnitude 
.Z magnitude 
.direction 


.X magnitude 
.y . magnitude 
.Z, magnitude 
.direction 


.X magnitude 
.y magnitude 
.Z magnitude 
-direction 


.x_magnitude 


y_magnitude 
z magnitude 
direction 


"n H H II 


center2kt 
center2kt 
center2kt 
center2kt 


lower2kt 
lower2kt 
lower2kt 
lower2kt 


[row] [col] .x_magnitude 
[row] [col] .y_magnitude 
[row] [col] .z_magnitude 
[row] [col] .direction 


[row] [col] .x_magnitude 
[row][col].y. magnitude 
[row][col].z magnitude 
[row][col].direction 


row « FLOWFIELDLENGTH; 
col « FLOWFIELDWIDTH; 


l H H H 


гом++) { 
со1++) { 


globaliktgrid[row] [col] 
globaliktgrid[row] [col] 
globallktgrid[row] [col] 
globaliktgrid[row] [col] 


globallktgrid[row] [col] 
globallktgrid[row] [col] 
globallktgrid[row] [col] 
globaliktgrid[row] [col] 


.X magnitude 
.y magnitude 
.Z magnitude 
.direction ; 


.X magnitude 
.y magnitude 
.Z, magnitude 
.direction ; 


globallktgrid[row]([col].x magnitude 
globallktgrid[row][col].y magnitude 
globallktgrid[row][col].z magnitude 
globallktgrid[row][col].direction ; 


globaliktgrid[row][col] 
globaliktgrid[row] [col] 
globaliktgrid[row] [col] 
globallktgrid[row] [col] 


globaliktgrid[row] [col] 
globaliktgrid[row] [col] 
globaliktgrid[row] [col] 
globaliktgrid[row] [col] 


global2ktgrid[row] [col] 
global2ktgrid[row] [col] 
global2ktgrid[row] [col] 
global2ktgrid[row] [col] 


global2ktgrid[row] [col] 
global2ktgrid[row] [col] 
global2ktgrid[row] [col] 
global2ktgrid[row] [col] 


.X magnitude 
.y magnitude 
.Z magnitude 
.direction ; 


.X magnitude 
.y . magnitude 
.Z magnitude 


-direction ; 


.X magnitude 
.y magnitude 
.Z magnitude 
.direction ; 


.Xx magnitude 
.y. magnitude 
.Z magnitude 
~directron 7 


global2ktgrid[row] [col] .x_magnitude 
global2ktgrid[row] [col] .y_magnitude 
global2ktgrid[row] [col] .z_magnitude 
global2ktgrid[row] [col] .direction ; 


global2ktgrid[row] [col] .x_magnitude 
global2ktgrid[row] [col] .y_magnitude 
global2ktgrid[row] [col] .z_magnitude 
global2ktgrid[row] [col] .direction ; 
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below2kt 
below2kt 
below2kt 
below2kt 


above3kt 
above3kt 
above3kt 
above3kt 


upper3kt 
upper3kt 
upper3kt 
upper3kt 


center3kt 
center3kt 
center3kt 
center3kt 


lower3kt 
lower3kt 
lower3kt 
lower3kt 


below3kt 
below3kt 
below3kt 
below3kt 


.X_magnitude 
.y magnitude 
.Z magnitude 
.direction 


[row] [col] 
[row] [col] 
[row] [col] 
[row] [col] 


Hl H H li 


.x_magnitude 
.y_magnitude 
.z_magnitude 
direction 


[row] [col] 
[row] [col] 
[row] [col] 
[row] [col] 


[row] [col] 
[row) [col] 
[row] [col] 
[row] [col] 


.X magnitude 
.y magnitude 
.Z magnitude 
.direction 


[row] [col] .x_magnitude 
[row][col].y magnitude 
[row][col].z magnitude 
[row] [col] .direction 


[row] [col].x_magnitude 
[row] [col].y_magnitude 
[row] [col].z_magnitude 
[row] [col] .direction 


[row] [col] 
[row] [col] 
[row] [col] 
[row] [col] 


.X magnitude 
.y magnitude 
.Z magnitude 
.direction 


) //End of col loop 
} //End of Row loop 


HW N 


global2ktgrid[row] [col] 
global2ktgrid[row][col] 
global2ktgrid[row][col] 
global2ktgrid[row] [col] 


global3ktgrid[row] [col] 
global3ktgrid[row] [col] 
global3ktgrid[row] [col] 
global3ktgrid[row] [col] 


global3ktgrid[row] [col] 
global3ktgrid[row] [col] 
global3ktgrid[row] [col] 
global3ktgrid[row] [col] 


.X magnitude 
.y magnitude 
.Z magnitude 


.direction 


. 
, 


.x_magnitude 
.y magnitude 
.Z magnitude 


.direction 


б 
, 


.X magnitude 
.y. magnitude 
.Z magnitude 


.direction 


, 


global3ktgrid[row][col].x magnitude 
global3ktgrid[row][col].y magnitude 
global3ktgrid[row][col].z magnitude 
global3ktgrid[row][col].direction ; 


global3ktgrid[row] [col] 
global3ktgrid[row] [col] 
global3ktgrid[row] [col] 
global3ktgrid[row] [col] 


global3ktgrid [row] [col] 
global3ktgrid[row] [col] 
global3ktgrid[row] [col] 
global3ktgrid[row] [col] 


//Update the tube level flow fields to show the tube flow 


//disturbances 


double before_tube_force 


double after_tube_force 


1.0; 
-1.0; 


For (int along_null s 
before tube force - 
for (int out, from hull 


abovelkt [along hull)[out from hull].x magnitude 
upperlkt [along hull][out from hull].x magnitude 
centerlkt[along hull] [out. from hull].x magnitude 
lowerlkt [along hull][out from hull].x magnitude 
[alongchut!l[out-from hull] 
above2kt [along hull] [out.from hull] 
upper2kt [along hull][out. from hull] 
center2kt[along. hull] [out. from hul1] 
lower2kt [along hul1][out. from hull) 
below2kt [along hull] [out from hull] 
above3kt [along hull][out. from hull] 
upper3kt [along hull][out from hull] 
center3kt[along hull][out from hull] 
lower3kt [along hull][out from hu1l1] 
below3kt [along hull] [out. from hull] 


belowlkt 


S 
IOF 


along_hull <= 60; 


.X magnitude 
.y magnitude 
.Z magnitude 


.direction 


. 
, 


.X magnitude 
.y magnitude 
.Z magnitude 


.direction 


, 


along hull-««) { 


=O οἱ from hull <= ЗО οἱ Έτους πι ιτ) { 


before tube force 
before tube force 
before tube force 
before tube force 
before tube force 
before tube force 
before tube force 
before tube force 
before tube force 
before tube force 
before tube force 
before tube force 
before tube force 
before tube force 
before tube force 


.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 


before tube force - before tube force - 0.032; 
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for ( along _hull = 61 Jalong hull <= 80; 
after tube_force = -1.0; 
for (int out Έτοα ΠΜ το, ος Έέεοῃ ПОТ =з 


abovelkt [along hull][out. from hull] 
upperlkt [along hull][out from hull] 
centerlkt[along hull][out from hull] 
lowerlkt [along. hull] [out. from hu11l] 
belowlkt [along hull][out. from hull] 
above2kt [along hull][out. from hull] 
upper2kt [along hull][out from hull] 
center2kt[along. hull][out. from hull] 
lower2kt [along hull][out. from hull] 
below2kt [along hull][out from hull] 
above3kt [along hull][out from hull] 
upper3kt [along hull][out, from hull] 
center3kt[along hu11][out. from hull] 
lower3kt [along hull][out. from hull] 
below3kt [along hull][out from hull] 


after tube force - 


along hull««) ( 


.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X, magnitude 
.X, magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 
.X magnitude 


l Hu H H wm m Hu H mn Hu n n Hn m" d 


after tube force + 0.032; 


out from hull-4-*) ( 


after tube force 
after tube force 
after tube force 
after tube force 
after tube force 
after tube force 
after tube force 
after tube force 
after tube force 
after tube force 
after tube force 
after tube force 
after tube force 
after tube force 
after tube force 


//Output the flow field arrays to the proper files 


for (int rowl = ο; 
σσ πε οσοι. ο 


rowl < FLOWFIELDLENGTH; 
coll < FLOWFIELDWIDTH; 


rowl++) { 
со11++) { 


abovetubeLevellktOutput «« rowl «« " " «« coll «« " " 

«« abovelkt [rowl][coll1].x magnitude << " " 

«« abovelkt [rowl][coll].y magnitude << " " 

«« abovelkt [rowl][coli].z magnitude << " " 

«« abovelkt [rowl][coli].direction «« endl; 
upperLevellktOutput << rowl << " " «« coll «« " " 

«« upperlkt [rowl][coll].x magnitude << " " 

«« upperlkt [rowl][coll].y magnitude «« " " 

«« upperlkt [rowi][coli].z magnitude << " " 

<< upperlkt [rowl] [coll] direction << end1; 
centerLevellktOutput << Yowl sza " “ << coll <<a? 

<< centerikt [rowl][coll1].x magnitude << " " 

<< centerlkt [row1][coll].y magnitude << " " 

<< centerlkt [rowl][coll].z magnitude «« " " 

«« centerlkt [rowl1][coll].direction «« endl; 
lowertubeLevellktOutput << rowl << " " << coll «« " " 

«« lowerlkt [rowl][coll].x magnitude «« " " 

«« lowerlkt [rowl][coll1].y magnitude «« " " 

<< lowerlke [rowl] [coll].z magnitude << " " 

<< lowerlkt [row1] [col1].direction << endl; 
belowLevellktOutput << rowl <= * Z< coll << " Q" 

«« belowlkt [rowl1][coll1].x magnitude «« " " 

<< belowlkt [rowl1][coll].y magnitude << " " 

«« belowlkt [rowl][coll].z magnitude «« " " 

«« belowlkt [rowl][coli].direction «« endl; 
abovetubeLevel2ktOutput << rowl << " " << coll «« " " 

«« above2kt [rowl][coll].x magnitude << " " 
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«« above2kt [rowl][coll].y.magnitude << " " 
«« above2kt [rowl][coll1].z magnitude << " " 
«« above2kt [row1][coll1].direction «« endl; 


upperLevel2ktOutput =<) rowl << eo c. 
<< upper2kt [rowl][coll].x magnitude << " " 
<< upper2kt [row1][coll].y_magnitude << " 
<< upper2kt [rowl][co1l1l] z_magnitude << " " 
«« upper2kt [rowi][colll.direction «« endl; 


centerLevel2ktOutput οὐ] << “ureo Ee 
<< center2kt [rowl] [coll] .x_magnitude << " " 
«« center2kt [rowi][coll].y magnitude «« " " 
«« center2kt [rowl1][coll1].z magnitude «« " " 
«« center2kt [rowl][coll].direction «« endl; 


lowertubeLevel2ktOutput «« rowl «« " " «« coll«« " " 
«« lower2kt [rowl][coll].x magnitude «« " " 
«« lower2kt [rowl][coll].y magnitude «« " " 
<< lower2kt [rowl][coll].z magnitude << " " 
«« lower2kt [row1] [col1] .direction << endl; 


belowLevel2ktOutput << του] << "'".* << Coll << mun 
<< below2kt [rowl][coll].x magnitude «« " " 
«« below2kt [rowl][coll].y magnitude «« " " 


«« below2kt [rowl][coll].z magnitude «« " " 
<< below2kt [rowl][coli].direction «« endl; 


abovetubeLevel3ktOutput << rowl << “ " << coll << " " 
<< above3kt [row1][col1].x_magnitude << " " 
<< above3kt [rowl][coll].y magnitude << " " 
<< above3kt [rowl][coll].z magnitude << " " 
<< above3kt [row1] [col1].direction << endl; 


upperLevel3ktOutput ЕТОЙ κο " ".««c collec ш; 
«« upper3kt [rowl][coll].x magnitude << " " 
«« upper3kt [rowl][coll].y magnitude << " " 
«« upper3kt [rowl][coll].z magnitude << " " 
«« upper3kt [rowl][coll].direction «« endl; 


centerLevel3ktOutput © тоу! ες "—* << coll << ©" 
«« center3kt [rowl1][coll].x magnitude << " " 
«« center3kt [rowl1][coll].y. nagnitude << " " 
«« center3kt [rowl][coll].z magnitude «« " " 
<< center3kt [rowl][coll] direction «« endl; 


lowertubeLevel3ktOutput << rowl << " " << coll << " " 
«« lower3kt [rowi][coll].x magnitude «« " " 
«« lower3kt [rowl1][coll].y magnitude «« " " 
<< lower3kt [rowl][coll].z magnitude «« " " 
<< lower3kt [row1] [col1] .direction << endl; 


belowLevel3ktOutput οσο. ο " << coll «« * " 
<< below3kt [rowl][coll].x magnitude << " " 
<< below3kt [rowl][coll].y.magnitude << " " 
«« below3kt [rowl][coll].z magnitude << " " 
<< below3kt [row1][col1].direction << endl; 


ИУ ЕПА Of colli loop 
} //End of Rowl loop 


//Close all Files for later use by dynamics/gnuplot 
abovetubeLevellktOutput.close(); 
upperLevellktOutput.close(); 
centerLevellktOutput.close(); 
lowertubeLevellktOutput.close(); 
belowLevellktOutput.close(); 


abovetubeLevel2ktOutput.close(); 
upperLevel2ktOutput.close(); 
centerLevel2ktOutput.close(); 
lowertubeLevel2ktOutput.close(); 
belowLevel2ktOutput.close(); 


abovetubeLevel3ktOutput.close(); 
upperLevel3ktOutput.close(); 
centerLevel3ktOutput.close(); 
lowertubeLevel3ktOutput.close(); 
belowLevel3ktOutput.close(); 


return; 


//This is the driver to run the flateplate flow generation and 
//tube level flow generacion functions 
main () { 
cout << "Starting the Flow Field Generation program." << endl; 
cout << "Generating the Flow Profiles for the Flat Plate Model Area." << endl; 


flatPlateFlowFieldGenerator ( ); 


cout << endl << endl; 


cout << "The following File(s) were created for use by the Phoenix AUV UVW: " << 
endl; 

cote flatplateflowfieldlkt.data" «« endl; 

COUP xe " flatplateflowfield2kt.data" «« endl; 

cout «« " flatplateflowfield3kt.data" «« endl; 

Cour << " flatprofile.data" «« endl; 

GOUE << * flatslice50.data" << endl; 

cout «« " flatslicelO0.data" «« endl; 

coub «« “ flatslicel50.data" «« endl; 

cout <<" flatslice200.data" << endl; 

cout. << w flatslice250.data" << endl; 

cout << endl << endl; 

cout << "Creating the Flow Profiles for the Tube Level Flow Areas." << endl; 

tubeLevelFlowFieldGenerator (); 

cout << "The following File(s) were created for use by the Phoenix AUV UVW: " << 
endl; 

СОМ << abovetubelevellkt.data" «« endl; 

cout «« " uppertubelevellkt.data" «« endl; 

Gout, << ^" centertubelevelikt.data" << endl; 

οσους <a" lowertubelevellkt.data" << endl; 

cout << " belowtubelevellkt.data" << endl; 

cout << endl; 

cout << " abovetubelevel2kt.data" «« endl; 

сом << w uppertubelevel2kt.data" << endl; 

сопе" centertubelevel2kt.data" «« endl; 
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) 


cout 
cout 
cout 
cout 
cout 
cout 
cout 
cout 
cout 


cout 


return O0; 


<< 
<< 
<< 
<< 
<< 
<< 
<< 
<< 
<< 


<< 


// end main 


: lowertubelevel2kt.data" «« endl; 

: belowtubelevel2kt.data” << endl; 

endl; 

abovetubelevel3kt.data" << endl; 

: uppertubelevel3kt.data" «« endl; 

centertubelevel3kt.data" << endl; 
: lowertubelevel3kt.data" << endl; 

belowtubelevel3kt.data" << endl; 


endl << endl; 


"Exiting the Flow Field Generation Program." << endl; 
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APPENDIX E. SIMULATION VIDEO 


bh INTRODUCTION 


The attached video appendix gives an overall view of the Phoenix AUV virtual environment. 


АП major objects are described and viewed. 


2. SURFACE BUOYANCY AND WAVE MOTION 


In this segment the AUV is run on a course into the seas in various sea states. The test runs 


demonstrate a sea state of 1, 3, and 5 respectively. 


3. PUMP OUTLETS/INLETS 


This part of the demonstration shows the AUV driving past a pump discharge outlet followed 
by a pump suction inlet. It demonstrates how the effects of turbulent flow are felt by the AUV, and 


how the AUV maintains stability and continues on the preplanned course. 


4. COMPLETE MISSION 


This is the final portion of the simulation tape. It shows a complete torpedo tube launch and 
recovery mission. The AUV is launched from a lower port torpedo tube, proceeds into the open water, 
takes position at the submarines stern and then conducts a docking evolution with the upper port 
torpedo tube. Both inward and outward outer door openings are assumed, ans simply represented 


using cylinders. 


5. INVOCATION INSTRUCTIONS 


To reproduce this mission the following steps should be taken. 
A. Start the viewer application as follows. 
SGI> viewer 


2. Start the dynamics portion of the program as follows 


SGI» dynamics 
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OR 


SGI» dynamics nosonar 


*****I[nsert dynamics Menu Capture xx * 


C. After dynamics is running select the option to conduct a torpedo tube docking 
evolution (it is letter *z"). 

D. Once all flow field arrays are initialized, select 'l" to loop the dynamics with the 
execution level. 

E Finally, launch the execution application as follows: 
SGI> execution mission mission.script.FlowFieldGenerator 
remote <dynamics host name> 


p You should now observe a torpedo tube launch and recovery mission in the viewer. 
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